<unnamed>

Public Key

npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7h

Profile Code

nprofile1qqsgdaptedm2gvwp9z6edsm8zjh88fpv4ey8q65725faw9syx3rltmqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc84cr0

Publishing to

relay.primal.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 17:33:19 CEST

- reply

📅 Original date posted:2015-05-08
📝 Original message:On 05/08/2015 01:13 AM, Tom Harding wrote:
> On 5/7/2015 7:09 PM, Jeff Garzik wrote:
>> G proposed 20MB blocks, AFAIK - 140 tps
>> A proposed 100MB blocks - 700 tps
>> For ref,
>> Paypal is around 115 tps
>> VISA is around 2000 tps (perhaps 4000 tps peak)
>>
For reference, I'm not "proposing" 100 MB blocks right now. I was
simply suggesting that if Bitcoin is to *ultimately* achieve the goal of
being a globally useful payment rails, 7tps is embarrassingly small.
Even with off-chain transactions. It should be a no-brainer that block
size has to go up.
My goal was to bring some long-term perspective into the discussion. I
don't know if 100 MB blocks will *actually* be necessary for Bitcoin in
20 years, but it's feasible that it will be. It's an open, global
payments system. Therefore, we shouldn't be arguing about whether 1 MB
blocks is sufficient--it's very clearly not. And admitting this as a
valid point is also an admission that not everyone in the world will be
able to run a full node in 20 years.
I don't think there's a solution that can accommodate all future
scenarios, nor that we can even find a solution right now that avoids
more hard forks in the future. But the goal of "everyone should be
able to download and verify the world's global transactions on a
smartphone" is a non-starter and should not drive decisions.

2023-06-07 17:33:17 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing "full" now. And by "full" he means
that the reliability of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks). I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions. In other words, we're very close to the
effective limit in terms of maintaining the current "standard of
living", and with a year needed to raise the block time this actually is
urgent.
(2) Leveraging fee pressure at 1MB to solve the problem is actually
really a bad idea. It's really bad while Bitcoin is still growing, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability). But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system. It is a couple orders of magnitude too low
for any meaningful commercial activity to occur. If we continue with a
cap of 7 tps forever, Bitcoin *will* fail. Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure). We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low.
You can argue that side chains and payment channels could alleviate
this. But how far off are they? We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way. Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.
We get asked all the time by corporate clients about scalability. A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle. We always assure them that 7 tps
is not the final answer.
Satoshi didn't believe 1 MB blocks were the correct answer. I
personally think this is critical to Bitcoin's long term future. And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.
-Alan
On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/8d08315a/attachment.html>

2023-06-07 17:29:02 CEST

- reply

📅 Original date posted:2015-01-23
📝 Original message:The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it if
they don't want to upgrade their signers. The proposal simply provides
a way to optionally sign the input values with the TxOut scripts. In
other words a signature right now says "I sign this transaction using
these inputs, whatever value they are." With this SIGHASH type, the
signature says "I sign this transaction assuming that input 0 is X BTC,
input 1 is Y BTC,....". If the online computer providing the data to be
signed lies about the value of any input, the resulting signature will
be invalid.
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations of it required the coins being spent to have been
originated in a special way. In other words, it would only work if the
coins had entered the wallet with some special, modified TxOut script.
So it wouldn't work with existing coins, and would require senders to
update their software to reshape the way they send transactions to be
compatible with our goals.
I *strongly* encourage this to be considered for inclusion at some
point. Not only does it simplify HW as Marek suggested, it increases
the options for online-offline communication channels, which is also a
win for security. Right now, QR codes don't work because of the
possibility of having to transfer megabytes over the channel, and no way
to for the signer to control that size. With this change, it's possible
for the signer to control the size of each chunk of data to guarantee it
fits in, say, a QR code (even if it means breaking it up into a couple
smaller transactions).
-Alan
On 01/23/2015 09:51 AM, slush wrote:
> Hi,
>
> is any progress or even discussion in this area?
>
> https://bitcointalk.org/index.php?topic=181734.0
>
> I don't insist on any specific solution, but this is becoming a real
> issue as hardware wallets are more widespread. I'm sitting next to
> TREZOR for 40 minutes already, because it streams and validate some
> complex transaction. By using proposed solution, such signature would
> be a matter of few seconds.
>
> That's also not just about time/resource/hw cost optimization. I'm
> talking about possibility of huge simplification of the firmware
> (=security FTW), because 50% of actual codebase is solving this
> particular downside of Bitcoin protocol.
>
> So, there's real world problem. On which solution can we as a
> community find a wide agreement?
>
> Best,
> Marek
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/46e022bd/attachment.html>

2023-06-07 17:28:36 CEST

- reply

📅 Original date posted:2015-01-19
📝 Original message:I'm a bit confused. It's been a long time since I looked at protobuf
(and will have to dig into it soon), but I seem to recall it doesn't
have any of the determinism properties you guys just said. It is
intended to allow you to skip details of the on-the-wire representations
and just send a bunch of named fields between systems. I thought there
was no guarantee that two identical protobuf structures will get
serialized identically...?
On 01/19/2015 02:57 PM, Richard Brady wrote:
> Thanks guys, great answers.
>
> The design choice certainly makes a lot more sense now regardless of
> whether one agrees with it or not.
>
> Regards,
> Richard
>
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150119/c6c82c2c/attachment.html>

2023-06-07 17:26:05 CEST

- reply

📅 Original date posted:2014-10-01
📝 Original message:On 10/01/2014 04:58 PM, Gavin Andresen wrote:
> If the first transaction is P2SH, then the miner won't know there is
> an advantage to holding it until it is too late (the scriptPubKey is
> an opaque hash until the second transaction is final and
> relayed/broadcast).
If you're doing some kind of proof-of-burn scheme, wouldn't using P2SH
defeat the purpose of it?

2023-06-07 17:25:52 CEST

- reply

📅 Original date posted:2014-09-23
📝 Original message:This topic has been touched on briefly here before, but I wanted to
solidify it and propose it as a BIP if there is wider support for it.
Also, the topic is difficult to discuss without lots of pictures -- so
that's what I've done (mainly to describe it to my team, but also as
general documentation). It's in presentation form:
https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf
The proposal is that for an M-of-N multisig wallet based on BIP32, there
should be N internal chains and N external chains. Each party is
assigned a chain based on the lexicographic ordering of their wallet's
root public key in the multisig. This guarantees that no parties are
generating and distributing the same addresses, and also provides a
certain level of built-in book-keeping. Coins being received on chain
2*x were created by participant x (receiving), and coins received on
2*x+1 are change outputs created by participant x (outgoing). Thus,
it's easy from simply looking at the wallet structure who was
responsible for which transactions.
Alternatively, we could change it to suggest that each "device" is
assigned a pair of chains. For a 2-of-3 there may 3 participants plus a
CFO with a "watch-only" version of the multisig wallet. Then you might
use four pairs of chains. I'm just not sure how they would be assigned.
If this has been proposed before, then consider this my contribution to
documentation.
-Alan
P.S. -- "No-Collision Mode" is not a great name. Happy to take
suggestions for changing it.

2023-06-07 17:24:37 CEST

- reply

📅 Original date posted:2014-07-30
📝 Original message:Hi Everyone,
The Armory team is pleased to announce the official release of our
decentralized multi-signature interface, called "Lockboxes". It is a
"true" multi-signature transaction interface:
* Decentralized multi-sig (no third-party servers or signers needed)
* Any multi-sig from 1-of-2 up to 7-of-7
* Any or all of the signing devices can be *offline*
* All private keys can be generated and managed independently
* Works with existing Armory wallets
* Simultaneous funding ("simulfunding") features for escrow and
contracts (basically CoinJoin)
* All wrapped up in a nice graphical user interface!
Armory 0.92 includes a GUI for creating, funding and spending from
multi-signature lockboxes, anything from 1-of-2 up to 7-of-7. All
private keys can be generated independently and never have to be
co-located. Most importantly, any number of the signing keys can be
created and managed on offline computers! Also, all transaction and
signature data is communicated directly between parties/devices using
ASCII-armored blocks of text, so no third-party servers/services are
needed (though, in the future, we hope to provide an optional service to
help synchronize the data between parties).
The release also includes the ability to do simultaneous funding
("simulfunding") which is basically CoinJoin through a GUI, but intended
to be used for contracts and escrow. Each party creates a "promissory
note" (which is basically just a list of UTXOs and a change address),
and those can be merged into a single transaction to be signed by all
funders. Either all contributions are made simutaneously, or none of
them are. There is no other outcome. This means that no trust is
required between the simulfunders. It is a basic contract enforced by
the bitcoin network itself.
Simulfunding would normally be used in conjuction with multi-signature
lockboxes -- two parties that don't trust each other together create a
lockbox, and then simultaneously fund it (and subsequently spend it)
according to some agreement. However, it can actually be used to
simulfund any address. To promote this feature, Armory Technologies Inc
is offering to match up to 20 BTC in donations to the EFF, FSF, College
Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation
(and hopefully wikipedia, as a late addition to the list). We posted
a list of ATI "promissory notes" for matching donations on our
website: https://bitcoinarmory.com/donation-match-list/
We're very excited about this release, which has been in testing for
over three months, and we've been using for management of company funds
between officers for the last two months. We have not seen anything
else that comes close to matching the flexibility and security afforded
by it (and without being exceptionally inconvenient!). See our
tutorials, and especially the FAQ at the end:
https://bitcoinarmory.com/about/using-lockboxes
https://bitcoinarmory.com/about/using-lockboxes/#faq
We hope that people will try it out and provide feedback. Maybe even
match some donations! We've already matched 3 BTC so far and it was
announced less than 24 hours ago.
Cheers,
-Alan
------
Press Release:
http://finance.yahoo.com/news/armory-releases-first-decentralized-multi-233500704.html
------
Changelog:
*VERSION 0.92**
**Released July 29, 2014**
*
- *Multi-Signature Lockboxes!*
Full-featured interface for creating multi-signature addresses,
putting money into them, and collecting signatures to spend them.
See our tutorials at:
https://bitcoinarmory.com/about/using-lockboxes/
- *Simulfunding for Addresses and Lockboxes*
Use the "Multi-Sig" menu to do prepare simulfunding to any
arbitrary address. Or click on the "Simul" checkbox in the
lockbox manager if you are simulfunding a lockbox. As a promotion
for this feature we are matching up to 20 BTC worth donations
to organizations that support Bitcoin, digital security, online
freedoms, and open-source software. See our donation list (with
instructions): https://bitcoinarmory.com/about/donation-match-list
- *Improved Mac/OSX Stability*
We merged a couple Qt4 patches that dramatically improved
compatibility on OSX 10.7 and newer. Should work with the
upcoming release of OSX 10.10.
- *Armory Daemon/API Upgrades (Beta)*
The Armory API has been upgraded substantially since version 0.91.
This version has tons of new functionality matching bitcoind,
as well as unique functionality including lockbox operations.
Plan to have complete functionality implemented and tested by
version 0.93.
- *Upgraded Transaction History Export to CSV*
Added running balance reporting for individual and all wallets.
Also fixed a bug where internal transfers within wallets were
not being reported properly.
- *Root PUBLIC Key Export*
You can now export just the root public key data that allows
you to reconstruct your watching-only wallet. It is five lines
that are easily printed or copied by hand. Could be used to
provide someone a chain of addresses for multiple payments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140730/d0ee6702/attachment.html>

2023-06-07 17:23:34 CEST

- reply

📅 Original date posted:2014-07-04
📝 Original message:On 07/04/2014 07:15 AM, Andy Parkins wrote:
> On Friday 04 July 2014 06:53:47 Alan Reiner wrote:
>
>> ROMix works by taking N sequential hashes and storing the results into a
>> single N*32 byte lookup table. So if N is 1,000,000, you are going to
>> compute 1,000,000 and store the results into 32,000,000 sequential bytes
>> of RAM. Then you are going to do 1,000,000 lookup operations on that
>> table, using the hash of the previous lookup result, to determine the
>> location of next lookup (within that 32,000,000 bytes). Assuming a
>> strong hash function, this means its impossible to know in advance what
>> needs to be available in RAM to lookup, and it's easiest if you simply
>> hold all 32,000,000 bytes in RAM.
> My idea wasn't to make hashing memory hungry; it was to make it IO-hungry. It
> wouldn't be too hard to make an ASIC with 32MB of RAM. Especially if it
> gained you a 1000x advantage over the other miners. It seems that sort of
> solution is exactly the one that Mike Hearn was warning against in his blog.
I think you misundersood.... using ROMix-like algorithm, each hash
requires a different 32 MB of the blockchain. Uniformly distributed
throughout the blockchain, and no way to predict which 32 MB until you
have actually executed it. If the difficulty is high enough, your
miner is likely to end up going through the entire X GB blockchain while
searching for a good hash, but other nodes will only need to do 32 MB
worth of disk accesses to verify your answer (and it will be unknown
which 32 MB until they do the 1,000,000 hash+lookup operations on their
X GB blockchain).
I think that strikes a good compromise of needing access to 100% of the
blockchain, without requiring reading 20 GB to verify a block.
(Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated
numbers in the future)

2023-06-07 17:23:33 CEST

- reply

📅 Original date posted:2014-07-04
📝 Original message:Just a thought on this -- I'm not saying this is a good idea or a bad
idea, because I have spent about zero time thinking about it, but
something did come to mind as I read this. Reading 20 GB of data for
every hash might be a bit excessive. And as the blockchain grows, it
will become infeasible to continue. However, what comes to mind is the
ROMix algorithm defined by Colin Percival, which was the pre-cursor to
scrypt. Which is actually what Armory uses for key stretching because
it's far simpler than scrypt itself while maintaining the memory-hard
properties (the downside is that it's much less flexible in allowing the
user to trade-off compute time vs memory usage).
ROMix works by taking N sequential hashes and storing the results into a
single N*32 byte lookup table. So if N is 1,000,000, you are going to
compute 1,000,000 and store the results into 32,000,000 sequential bytes
of RAM. Then you are going to do 1,000,000 lookup operations on that
table, using the hash of the previous lookup result, to determine the
location of next lookup (within that 32,000,000 bytes). Assuming a
strong hash function, this means its impossible to know in advance what
needs to be available in RAM to lookup, and it's easiest if you simply
hold all 32,000,000 bytes in RAM.
Something similar could be applied to your idea. We use the hash of a
prevBlockHash||nonce as the starting point for 1,000,000 lookup
operations. The output of the previous lookup is used to determine
which block and tx (perhaps which chunk of 32 bytes within that tx) is
used for the next lookup operation. This means that in order to do the
hashing, you need the entire blockchain available to you, even though
you'll only be using a small fraction of it for each "hash". This might
achieve what you're describing without actually requiring the full 20 GB
of reading on ever hash.
-Alan
On 07/04/2014 06:27 AM, Andy Parkins wrote:
> Hello,
>
> I had a thought after reading Mike Hearn's blog about it being impossible to
> have an ASIC-proof proof of work algorithm.
>
> Perhaps I'm being dim, but I thought I'd mention my thought anyway.
>
> It strikes me that he's right that it's impossible for any algorithm to exist
> that can't be implemented in an ASIC. However, that's only because it's
> trying to pick an algorithm that is CPU bound. You could protect against ASCI
> mining (or rather, make it irrelevant that it was being used) by making the
> algorithm IO-bound rather than CPU-bound.
>
> For example, what if the proof-of-work hash for a block were no longer just
> "hash of block", which contains the hash of the parent block, but instead were
> hash of
>
> [NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]
>
> [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing. By prefixing and
> suffixing the new block, you have to feed every byte of the blockchain through
> the hashing engine (the prefix prevents you caching the intermediate result).
> Whatever bus you're using to feed your high speed hashing engine, it will
> always be faster than the bus -- hence you're now IO-bound, not CPU-bound, and
> any hashing engine will, effectively, be the same.
>
> I'm making the assumption that SHA-256 is not cacheable from the middle
> outwards, so the whole block-chain _has_ to be transferred for every hash.
>
> Apologies in advance if this is a stupid idea.
>
>
>
> Andy

2023-06-07 17:20:46 CEST

- reply

📅 Original date posted:2014-05-02
📝 Original message:I've been a strong supporter of the 1e-6 unit switch since the beginning
and ready to do whatever I can with Armory to help ease that
transition. I'm happy to prioritize a release that updates the Armory
interface to make "bits" the default unit, when the time is right. I
think it makes sense to get as many apps and services to upgrade nearly
simultaneously.
My plan is to have a popup on the first load of the new version that
briefly introduces the change, and mentions that they can go back to the
old way in the settings, but make them work to do it. For the transient
period (6 months?) all input boxes will auto-update nearby labels with
the converted-to-BTC value as they type, so that they don't have to do
any math in their head. Similarly, all displayed BTC values will show
both. But the 1e-6 unit will always be default or first unless they
explicitly change it in the interface.
On 5/2/2014 8:54 PM, Ben Davenport wrote:
> I fully support this (it's what I suggested over a year ago), but what
> it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum
> around "bits", great.
>
> My only addition is that I think we should all stop trying to attach
> SI prefixes to the currency unit. Name me another world currency that
> uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted
> standard at least in the US is <currency-symbol><amount><modifier>,
> i.e. $63k or $3M. That may not be accepted form everywhere, but in any
> case it's an informal format, not a formal one. The important point is
> there should be one base unit that is not modified with SI prefixes.
> And I think the arguments are strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> <vendor hat: on>
>
> Related:
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform
> available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140502/44cb1298/attachment.html>

2023-06-07 17:20:18 CEST

- reply

📅 Original date posted:2014-04-26
📝 Original message:I will just chime in that I've been working on a similar spec for Armory
to implement P2SH multisig and I came up with basically an identical
scheme. I think you covered most of what is needed. The one thing I
did differently was try to match the BIP 32 structure, by keeping the
original 3 levels (wallet, chain, addresses), and use 2*N chains to
handle the N different parties generating receiving and change
addresses. It's not necessary, but it follows more closely the
three-level scheme that BIP 32 originally envisioned. I also concluded
that the chain indices are ordered by lexicographical sorting of root
public keys, but resorting each individual address. There are use cases
where it will be necessary for parties to know how to combine public
keys into a multi-sig address without knowing the root keys.
Also, for the purposes of one-off types of escrow multi-sig, we have
included a "wallet locator" field in the transaction that must be passed
around. This "wallet locator" is stored with each key (perhaps at the
time public keys are collected and merged), and passed around with
transactions to be signed. This allows lightweight devices like
hardware wallets, to recognize their own keys. It would encoded in a
VAR_STR, and doesn't have to be meaningful to the other participants --
each device would look at all signing slots in a transaction (either
singlesig or each key in a multisig) and would generate a public key
along each path, and see if the result matches. If so, it can sign it.
If not, it must be someone else's.
I bring this up, because this multisig wallet structure you're talking
about has a very simple "wallet locator" scheme -- all parties will use
the same locator for a given receiving address. But that field should
remain part of the data structure for each key, to accommodate all types
of multisig, not just linked/parallel tree schemes.
-Alan
On 04/25/2014 06:27 PM, Manuel Araoz wrote:
> Hi, I'm part of the team building copay
> <https://github.com/bitpay/copay>, a multisignature P2SH HD
> wallet. We've been following the discussion regarding standardizing
> the structure for branches both on this list and on github (1
> <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>, 2
> <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>, 3
> <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>, 4
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>, 5
> <https://github.com/bitcoin/bips/pull/52>). Soon, we realized the
> assumptions in the discussions were not true for a multisig hd wallet,
> so we wanted to share our current approach to that, to get feedback
> and see if we can arrive to a new standard (and possibly a new BIP)
>
> These are our assumptions:
> - N parties want to share an m-of-n wallet.
> - Each party must generate their master private keys independently.
> - Use multisig P2SH for all addresses.
> - Use BIP32 to derive public keys, then create a multisig script, and
> use the P2SH address for that.
> - The address generation process should not require communicating
> with other parties. (Thus, all parties must be able to generate all
> public keys)
> - Transaction creation + signing requires communication between
> parties, of course.
>
> -------------------------------------------------
>
> Following BIP43, we're be using:
> m / purpose' / *
> where /purpose/ is the hardened derivation scheme based on the new BIP
> number.
> We then define the following levels:
> m / purpose' / cosigner_index / change / address_index
> Each level has a special meaning detailed below:
>
> /cosigner_index/ <http://en.wikipedia.org/wiki/Co-signing>: the index
> of the party creating this address. The indices can be determined
> independently by lexicographically sorting the master public keys of
> each cosigner.
>
> /change/: 0 for change, 1 for receive address.
>
> /address_index/: Addresses are numbered from index 0 in sequentially
> increasing manner. We're currently syncing the max used index for each
> branch between all parties when they connect, but we're open to
> considering removing the index sync and doing the more elegant
> used-address discovery via a gap limit, as discussed in BIP44
> <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit>.
> We feel 20 might be too low though.
>
> *Wallet high-level description:*
> Each party generates their own extended master keypair and shares the
> extended purpose' public key with the others, which is stored
> encrypted. Each party can generate any of the other's derived public
> keys, but only his own private keys.
>
> *General address generation procedure:*
> When generating an address, each party can independently generate the
> N needed public keys. They do this by deriving the public key in each
> of the different trees, but using the same path. They can then
> generate the multisig script and the corresponding p2sh address. In
> this way, each path corresponds to an address, but the public keys for
> that address come from different trees.
>
> *Receive address case:*
> Each cosigner generates addresses only on his own branch. One of the n
> cosigners wants to receive a payment, and the others are offline. He
> knows the last used index in his own branch, because only he generates
> addresses there. Thus, he can generate the public keys for all of the
> others using the next index, and calculate the needed script for the
> address.
>
> /Example: /Cosigner #2 wants to receive a payment to the shared
> wallet. His last used index on his own branch is 4. Then, the path for
> the next receive address is m/$purpose/2/1/5. He uses this same path
> in all of the cosigners trees to generate a public key for each one,
> and from that he gets the new p2sh address.
>
> *Change address case:*
> Again, each cosigner generates addresses only on his own branch. One
> of the n cosigners wants to create an outgoing payment, for which
> he'll need a change address. He generates a new address using the same
> procedure as above, but using a separate index to track the used
> change addresses.
> /
> Example: /Cosigner #5 wants to send a payment from the shared wallet,
> for which he'll need a change address. His last used change index on
> his own branch is 11. Then, the path for the next change address is
> m/$purpose/5/0/12. He uses this same path in all of the cosigners
> trees to generate a public key for each one, and from that he gets the
> new p2sh address.
>
>
> *Transaction creation and signing:*
> When creating a transaction, first one of the parties creates a
> Transaction Proposal. This is a transaction that spends some output
> stored in any of the p2sh multisig addresses (corresponding to any of
> the copayers' branches). This proposal is sent to the other parties,
> who decide if they want to sign. If they approve the proposal, they
> can generate their needed private key for that specific address (using
> the same path that generated the public key in that address, but
> deriving the private key instead), and sign it. Once the proposal
> reaches m signatures, any cosigner can broadcast it to the network,
> becoming final. The specifics of how this proposal is structured, and
> the protocol to accept or reject it, belong to another BIP, in my
> opinion.
>
> *Final comments:*
> - We're currently lexicographically sorting the public keys for each
> address separately. We've read Mike Belshe's comments about sorting
> the master public keys and then using the same order for all derived
> addresses, but we couldn't think of any benefits of doing that (I
> mean, the benefits of knowing whose public key is which).
> - We originally thought we would need a non-hardened version of
> purpose for the path, because we needed every party to be able to
> generate all the public keys of the others. With the proposed path, is
> it true that the cosigners will be able to generate them, by knowing
> the extended purpose public key for each copayer? (m/purpose')
> - The reason for using separate branches for each cosigner is we don't
> want two of them generating the same address and receiving
> simultaneous payments to it. The ideal case is that each address
> receives at most one payment, requested by the corresponding cosigner.
>
>
> Thoughts?
> Manuel
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140425/c7d5c529/attachment.html>

2023-06-07 17:18:59 CEST

- reply

📅 Original date posted:2014-04-20
📝 Original message:Btw, I should clarify my email: I'm a staunch supporter of moving to
1e-6 BTC as the default unit for wallet applications, not necessarily
any particular name. I would be fine with "bits" as I think this
context is sufficiently different that it won't be confused by regular
consumers. But it wouldn't be my first choice. I don't know what my
first choice would be.
While writing this email, I asked my wife (who's been tired of hearing
about Bitcoin for two years), what she thinks of "bits", "microbes",
"micros". She said she is fine with any of them. Apparently microbes
reminders her of biology, not "germs". But she's also well-educated, so
she fine with milli, micro, kilo, etc... and apparently biology...
Whatever we call it. I'm happy to support it as long as it's 1e-6.
On 04/20/2014 12:23 PM, Erik Garrison wrote:
>
> The world is rapidly becoming a place in which a solid grasp of orders
> of magnitude could be considered a basic mathematical skill. People
> are very likely to learn what mBTC and µBTC are simply because they
> risk their money if they do not. This is not a bad thing and I think
> stands only to help people who learn about these monikers for orders
> of magnitude this way.
>
> Any appropriate nicknames for these denominations is sure to develop
> in due course. Promoting an already-overloaded term that could just
> as easily be applied colloquially to refer to a small amount of value
> in any currency seems problematic.
>
> I've been a staunch supporter of "microbitcoin" and would like to do
> anything I can to make sure that we jump directly to it if we're going
> to promote changing the default units. And I'm happy to integrate it
> into Armory as a default (with appropriate explanations and
> settings/options). I'm not so convinced about the "bits" name though
> -- I do like it, but I do also think that word is too overloaded.
> Though, I think we could get away with it.
>
> (Sadly, I still use "microbes" occasionally (as in *microb*itcoin)
> when I'm talking to coworkers, because it slips off the tongue and is
> actually a good combination of brevity and self-explanatory -- it just
> doesn't instill the right visuals...)
>
> We started integrating alternative units into Armory. But, of course,
> there were a few more loose ends than I expected, which will require
> some work. We want to put it in but not necessarily change the
> default right away. I'd /prefer/ we get some commitments from some
> other wallet developers, so we can make a unified push for it. I'm
> happy to lead that and make it default as long as I'm not the only one
> in the world doing it.
>
> -Alan
>
>
>
> On 04/20/2014 11:05 AM, Tamas Blummer wrote:
>> Here is an earlier reference to bits:
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
>> <https://www.mail-archive.com/[email protected]/msg04248.html>
>>
>> I forgot that Alan Reiner was also supporting a unit equals to bits :
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
>> <https://www.mail-archive.com/[email protected]/msg04264.html>
>>
>> and here the earlier going back to March 2013 and a poll at that time
>> pushing for XBT being 1 bit
>>
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
>> <https://www.mail-archive.com/[email protected]/msg04256.html>
>>
>> Regards,
>>
>> Tamas Blummer
>> http://bitsofproof.com
>>
>> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com
>> <mailto:pieter.wuille at gmail.com>> wrote:
>>
>>> I told him specifically to bring it here (on a pull request for
>>> Bitcoin Core), as there is no point in making such convention changes
>>> to just one client.
>>>
>>> I wasn't aware of any discussion about the "bits" proposal here before.
>>>
>>> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer
>>> <tamas at bitsofproof.com <mailto:tamas at bitsofproof.com>> wrote:
>>>> People on this list are mostly engineers who have no problem
>>>> dealing with
>>>> magnitudes and have rather limited empathy for people who have a
>>>> problem
>>>> with them.
>>>> They also tend to think, that because they invented money 2.0 they
>>>> would not
>>>> need to care of finance's or people's current customs.
>>>>
>>>> The importance of their decisions in these questions will fade as
>>>> people
>>>> already use wallets other than the core.
>>>>
>>>> Bring this particular discussion elsewhere, to the wallet developer.
>>>>
>>>> BTW the topic was discussed here several times, you have my support
>>>> and Jeff
>>>> Garzik's.
>>>>
>>>> Regards,
>>>>
>>>> Tamas Blummer
>>>> http://bitsofproof.com
>>>>
>>>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com>
>>>> <mailto:rob.golding at astutium.com> wrote:
>>>>
>>>> The average person is not going to be confident that the prefix they
>>>> are using is the correct one,
>>>>
>>>>
>>>> The use of any 'prefix' is one of choice and entirely unnecessary,
>>>> and there
>>>> are already established 'divisions' in u/mBTC for those that feel
>>>> they need
>>>> to use such things.
>>>>
>>>> people WILL send 1000x more or less than
>>>> intended if we go down this road,
>>>>
>>>>
>>>> Exceptionally unlikely - I deal every day with currencies with 0, 2
>>>> and 3
>>>> dp's in amount ranging from 'under 1 whole unit' to tens of
>>>> thousands - Not
>>>> once in 20 years has anyone ever 'sent' more or less than intended
>>>> - oh,
>>>> they've 'intended' to underpay just fine, but never *unintended*.
>>>>
>>>> I propose that users are offered a preference to denominate the
>>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>>>
>>>>
>>>> I propose that for people unable to understand what a bitcoin is,
>>>> they can
>>>> just use satoshi's and drop this entire proposal.
>>>>
>>>> Rob
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases
>>>> and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Learn Graph Databases - Download FREE O'Reilly Book
>>>> "Graph Databases" is the definitive new guide to graph databases
>>>> and their
>>>> applications. Written by three acclaimed leaders in the field,
>>>> this first edition is now available. Download your free book today!
>>>> http://p.sf.net/sfu/NeoTech
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development at lists.sourceforge.net
>>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/f67ef7e9/attachment.html>

2023-06-07 17:18:55 CEST

- reply

📅 Original date posted:2014-04-20
📝 Original message:I've been a staunch supporter of "microbitcoin" and would like to do
anything I can to make sure that we jump directly to it if we're going
to promote changing the default units. And I'm happy to integrate it
into Armory as a default (with appropriate explanations and
settings/options). I'm not so convinced about the "bits" name though --
I do like it, but I do also think that word is too overloaded. Though,
I think we could get away with it.
(Sadly, I still use "microbes" occasionally (as in *microb*itcoin) when
I'm talking to coworkers, because it slips off the tongue and is
actually a good combination of brevity and self-explanatory -- it just
doesn't instill the right visuals...)
We started integrating alternative units into Armory. But, of course,
there were a few more loose ends than I expected, which will require
some work. We want to put it in but not necessarily change the default
right away. I'd /prefer/ we get some commitments from some other wallet
developers, so we can make a unified push for it. I'm happy to lead
that and make it default as long as I'm not the only one in the world
doing it.
-Alan
On 04/20/2014 11:05 AM, Tamas Blummer wrote:
> Here is an earlier reference to bits:
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
> <https://www.mail-archive.com/[email protected]/msg04248.html>
>
> I forgot that Alan Reiner was also supporting a unit equals to bits :
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
> <https://www.mail-archive.com/[email protected]/msg04264.html>
>
> and here the earlier going back to March 2013 and a poll at that time
> pushing for XBT being 1 bit
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
> <https://www.mail-archive.com/[email protected]/msg04256.html>
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 20.04.2014, at 16:53, Pieter Wuille <pieter.wuille at gmail.com
> <mailto:pieter.wuille at gmail.com>> wrote:
>
>> I told him specifically to bring it here (on a pull request for
>> Bitcoin Core), as there is no point in making such convention changes
>> to just one client.
>>
>> I wasn't aware of any discussion about the "bits" proposal here before.
>>
>> On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer <tamas at bitsofproof.com
>> <mailto:tamas at bitsofproof.com>> wrote:
>>> People on this list are mostly engineers who have no problem dealing
>>> with
>>> magnitudes and have rather limited empathy for people who have a problem
>>> with them.
>>> They also tend to think, that because they invented money 2.0 they
>>> would not
>>> need to care of finance's or people's current customs.
>>>
>>> The importance of their decisions in these questions will fade as people
>>> already use wallets other than the core.
>>>
>>> Bring this particular discussion elsewhere, to the wallet developer.
>>>
>>> BTW the topic was discussed here several times, you have my support
>>> and Jeff
>>> Garzik's.
>>>
>>> Regards,
>>>
>>> Tamas Blummer
>>> http://bitsofproof.com
>>>
>>> On 20.04.2014, at 15:15, Rob Golding <rob.golding at astutium.com> wrote:
>>>
>>> The average person is not going to be confident that the prefix they
>>> are using is the correct one,
>>>
>>>
>>> The use of any 'prefix' is one of choice and entirely unnecessary,
>>> and there
>>> are already established 'divisions' in u/mBTC for those that feel
>>> they need
>>> to use such things.
>>>
>>> people WILL send 1000x more or less than
>>> intended if we go down this road,
>>>
>>>
>>> Exceptionally unlikely - I deal every day with currencies with 0, 2
>>> and 3
>>> dp's in amount ranging from 'under 1 whole unit' to tens of
>>> thousands - Not
>>> once in 20 years has anyone ever 'sent' more or less than intended - oh,
>>> they've 'intended' to underpay just fine, but never *unintended*.
>>>
>>> I propose that users are offered a preference to denominate the
>>> Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
>>> equals one million bits (bits) and one bit equals 100 satoshis.
>>>
>>>
>>> I propose that for people unable to understand what a bitcoin is,
>>> they can
>>> just use satoshi's and drop this entire proposal.
>>>
>>> Rob
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and
>>> their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140420/542338d8/attachment.html>

2023-06-07 17:16:42 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:Armory does exactly this: it defines the "Fragment ID" as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58. Then it explains to the user "All fragments with the same
fragment ID are compatible" (which only works if you use deterministic
coefficients). Each fragment is then labeled with "[FragID]-#1",
"[FragID]-#2", etc. It became quite useful for organizing the fragments
and documenting how I was distributing them, especially if I had printed
or saved the same fragment twice by accident.
On 03/29/2014 02:16 PM, Tamas Blummer wrote:
> I also think that we can add usability features if the underlying
> secret remains well protected.
> I do not think there is any reason to assume that the knowledge of the
> degree of the polynomial, would aid an attacker.
>
> Similarly a fingerprint of the secret if it is unrelated to the hash
> used in the polinomyal should leak no useful information,
>
> The length of such fingerpring (say 4 bytes) and the degree (1 byte)
> does not seem a big overhead for me.
>
> Remember that the biggest obstacle of Bitcoin is usability not security.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 29.03.2014, at 18:52, Alan Reiner <etotheipi at gmail.com
> <mailto:etotheipi at gmail.com>> wrote:
>
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from
>>> the shares because including it would give an adversary a vital
>>> piece of information. Likewise, including any kind of information
>>> that would allow a determination of whether the secret has been
>>> correctly reconstituted would give an adversary too much
>>> information. Failing silently when given incorrect shares or an
>>> insufficient number of shares is intentional.
>>
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> <mailto:Bitcoin-development at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/8e874f60/attachment.html>

2023-06-07 17:16:41 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:On 03/29/2014 02:00 PM, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
>> On 03/29/2014 01:19 PM, Matt Whitlock wrote:
>>> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
>> I do not believe this is a good tradeoff. It's basically obfuscation of
>> something that is already considered secure at the expense of
>> usability. It's much more important to me that the user understands
>> what is in their hands (or their family members after they get hit by a
>> bus), than to obfuscate the parameters of the secret sharing to provide
>> a tiny disadvantage to an adversary who gets ahold of one.
>>
>> The fact that it fails silently is really all downside, not a benefit.
>> If I have enough fragments, I can reconstruct the seed and see that it
>> produces addresses with money. If not, I know I need more fragments.
>> I'm much more concerned about my family having all the info they need to
>> recover the money, than an attacker knowing that he needs two more
>> fragments instead of which are well-secured anyway.
> For what it's worth, ssss also omits from the shares any information about the threshold. It will happily return a garbage secret if too few shares are combined. (And actually, it will happily return a garbage secret if too *many* shares are combined, too. My implementation does not have that problem.)
Regardless of how SSSS does it, I believe that obfuscating that
information is bad news from a usability perspective. Undoubtedly,
users will make lots of backups of lots of wallets and think they
remember the M-parameter but don't. They will accidentally mix in some
3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
or not able to distinguish them. Or they'll distribute too many
thinking the threshold is higher and end up insecure, or possibly not
have enough fragments to restore their wallet thinking the M-value was
lower than it actually was.
I just don't see the value in adding such complexity for the benefit of
obfuscating information an attacker might be able to figure out anyway
(most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
he doesn't know where the other frags are and they are actually in
safe-deposit boxes)

2023-06-07 17:16:40 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:On 03/29/2014 01:19 PM, Matt Whitlock wrote:
> I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.
I do not believe this is a good tradeoff. It's basically obfuscation of
something that is already considered secure at the expense of
usability. It's much more important to me that the user understands
what is in their hands (or their family members after they get hit by a
bus), than to obfuscate the parameters of the secret sharing to provide
a tiny disadvantage to an adversary who gets ahold of one.
The fact that it fails silently is really all downside, not a benefit.
If I have enough fragments, I can reconstruct the seed and see that it
produces addresses with money. If not, I know I need more fragments.
I'm much more concerned about my family having all the info they need to
recover the money, than an attacker knowing that he needs two more
fragments instead of which are well-secured anyway.

2023-06-07 17:16:40 CEST

- reply

📅 Original date posted:2014-03-29
📝 Original message:Armory has had "Fragmented Backups" for over a year, now. Advanced
users love it. Though, I would say it's kind of difficult to
standardize the way I did it since I was able to implement all the
finite field math with recursion, list comprehensions and python
arbitrary-big-integers in about 100 lines. I'm not sure how "portable"
it is to other languages. There's obviously better ways to do it, but I
didn't need a better way, because I don't need to support fragmentation
above M=8 and this was 100% sufficient for it. And I was the only one
doing it, so there was no one to be compatible with.
I won't lie, there's a lot of work that goes into making an interface
that makes this feature "usable." The user needs clear ways to identify
which fragments are associated with which wallet, and which fragments
are compatible with each other. They need a way to save some fragments
to file, print them, or simply write them down. They need a way to
re-enter fragment, reject duplicates, identify errors, etc. Without it,
the math fails silently, and you end up restoring a different wallet.
And they need a way to test that it all works. Armory did all this,
but it was no trivial task. Including an interface that will test up to
50 subsets of make sure the math produces the same values every time
(which still is not sufficient for some users, who won't be satisified
til they see they're wallet actually restored from fragments.
Also I put the secret in the highest-order coefficient of the
polynomial, and made sure that the other coefficients were
deterministic. This meant that if print out an M-of-N wallet, I can
later print out an M-of-(N+1) wallet and the first N fragments will be
the same. I'm not sure how many users would trust this, but we felt it
was important in case a user needs to export some fragments, even if
they don't increase N.
You might consider loading Armory in offline mode, create a wallet, and
then do a fragmented backup to see how we did it. I am extremely
satisfied with the interface, but it's most definitely an "advanced"
tool. But so is Armory ... which made it a good fit. But it might not
be for everyone.
-Alan
On 03/29/2014 11:44 AM, Matt Whitlock wrote:
> On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
>> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
> Thanks. This is great, although it makes some critical references to an ACM paper for which no URL is provided, and thus I cannot implement it.
>
> A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 master seed into shares. I am envisioning a scenario in which I might meet my sudden and untimely demise, and I wish to allow my beneficiaries to reconstruct my wallet's master seed after my death. I would like to distribute seed shares to each of my beneficiaries and some close friends, such that some subset of the shares must be joined together to reconstitute my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. I am presently working on extending my draft BIP so that it also applies to BIP32 master seeds of various sizes.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

2023-06-07 17:16:13 CEST

- reply

📅 Original date posted:2014-03-26
📝 Original message:This might be tangential, but the comment about "refund" chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1. Your spouse's
phone would use chains 2 and 3.
So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan
On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140326/35055a7c/attachment.html>

2023-06-07 17:15:37 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 01:51 PM, Mike Hearn wrote:
>
> Well it looks like the consensus is to do it, instead of talking
> about it. I'm going to make sure we get uBTC into the next Armory
> release.
>
>
> Hmm - be careful with the word "consensus" here. A bunch of people on
> a mailing list does not make consensus ;)
>
> If you survey other wallets, you'll find most already switched to
> mBTC, that it took some effort to do so (look at the size of the
> patches for instance) and that probably, nobody is super-keen to
> change again so soon. So uBTC would make you different to most of the
> other wallets and services in wide usage.
>
> If Armory wants to do that, that's no problem, maybe it will be a
> competitive advantage - just saying, don't quote this thread as
> indicating some kind of community consensus.
>
> Wallets and services that are using mBTC (that I know of)
>
> blockchain.info <http://blockchain.info>
> MultiBit
> Bitcoin Wallet (Android)
> Hive
> Bitcoinity
> KnC Wallet (defaults to BTC but can be switched to mBTC in settings,
> uBTC not an option)
> Mullvad
> btcstore.eu <http://btcstore.eu>
>
> Doing a google search for [bitcoin "mBTC"] and [bitcoin "uBTC"], the
> former has a bunch of sites and services with prices in mBTC. The
> latter only has faucets, as far as I can tell, which sort of makes sense.
I actually was not aware that so many had already switched to mBTC. I
guess it shows how much I use other wallets.
You misunderstood my "consensus" comment. I was simply stating the
"consensus" of debating on the mailing list endlessly is not as
effective as doing it. Thus I was just going to do it and see who
follows. But that also assumed there was not a critical mass who'd
already switched -- I must admit I'm not so confident anymore...
I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to
take a small leap of faith (with associated risks), to help push the
"consensus". Of course it would still remain configurable, but the
default will make a big difference.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/d0586965/attachment.html>

2023-06-07 17:15:35 CEST

- reply

📅 Original date posted:2014-03-13
📝 Original message:On 03/13/2014 10:32 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike at plan99.net> wrote:
>> BitPay should use mBTC as well. Unless you can point to any major wallets,
>> exchanges or price watching sites that use uBTC by default?
>>
>> I think it is highly optimistic to assume we'll need another 1000x shift any
>> time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard
> Such hand-wavy, data-free logic is precisely why community
> coordination is preferred to random apps making random decisions in
> this manner.
>
> mBTC is problematic because you do not need 1000x shift in value to
> produce annoyances for major accounting packages that are hard-limited
> to two decimal places. Further, spreadsheets hide information if
> formatting is configured naively -- that is, if formatting is
> configured for bitcoin the way it is configured for other currencies.
>
> Fundamentally, more than two decimal places tends to violate the
> Principle Of Least Astonishment with many humans, and as a result,
> popular software systems have been written with that assumption.
>
I whole-heartedly agree with Jeff. micro-BTC was the way to go to end
user confusion and make things easier for software systems which are
designed to handle money (i.e. two decimal places). I also echo the
sentiment about people being able to handle large numbers well.
We've been working with Marty Zigman who's creating a Bitcoin plugin for
NetSuite accounting platform, and he was already forced to switch
micro-BTC long ago for exactly the reasons described above. I think the
system will track up to 3 decimal places without causing all sorts of
heartache and automatic rounding.
Of course, as Mike said, this ship may have already sailed, but if
there's any way to revisit this, I'm there. We're just about to do
another Armory release and could support this very easily.

2023-06-07 17:15:08 CEST

- reply

📅 Original date posted:2014-03-12
📝 Original message:I might as well throw in a word about Armory. After our next release in
a couple weeks, we will be going full-speed at new wallets and BIP32
integration. Just like Jean-Pierre mentioned, we'll be using parallel
trees to generate P2SH addresses after sorting the keys
lexicographically. We plan to introduce the concept of a wallet
"bundle" (that name is far from concrete... I'd love a better word).
All wallets in a bundle are protected by the same backup, and stored in
the same file. The default behavior will be use new branches in the
same BIP32 tree when a user creates a new "wallet", though we will allow
multiple bundles in advanced and expert usermode (which is needed to
have watching-only wallets from a different seed created from an offline
computer).
However, we do plan to allow separate parties to create
multisig-intended wallets with public parts that can be exported and
combined with other users. We feel this is critical, as it allows for
linked wallets in which there was never a single-point of failure from
key-generation to signing. This is especially important for contexts
where employees may be handling a company's Bitcoins wallets.
On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I
was not clear whether those BIPs were worth prioritizing ... i.e. is
there a general consensus from a variety of wallet developers that they
should be supported? Rather, I'm happy to start prioritizing them if
others do too, but I haven't spent much time trying to understand them
to even know if they're mature, yet.
-Alan
On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote:
> Hello people,
>
> We are working on some of this stuff. We had some very early draft on
> how we envisioned multisig happening. It is all implemented in Haskoin
> available as multiple repositories in Github. I am happy to see this
> gathering momentum.
>
> Our multisig system uses BIP-0032 HD wallets, and there will soon be
> BIP-0039 support for keys compatibility.
>
> Our wallet uses synced trees rooted at the extended pubkeys of the
> participants. Currently we are sorting public keys in the scripts to
> avoid ambiguity.
>
> Download haskoin-wallet:
>
> cabal install haskoin-wallet
>
> Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
> bring transactions into the wallet. You must initialize first with a
> seed and create an account. It supports both regular and multisig accounts.
>
> Perhaps this can lead to interesting discussions on key exchange, and
> the appropriate handling of wallet metadata. I?d love to work on a
> proper standard that could lead us to compatible implementations.
>
> This document explains how we do it now:
>
> http://haskoin.com/~xeno/hd-multisig-wallet.html
>
> Cheers!
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140311/ed33704b/attachment.html>

2023-06-07 17:15:03 CEST

- reply

📅 Original date posted:2014-03-10
📝 Original message:As far as I'm concerned, the way forward is to scrap BIP 10 and build up
something new that is flexible and extensible. Also, my understanding
is that there may be room in the payment protocol for this stuff though
I'm not sure if it is really adapted well to all the steps: exchanging
public keys, creating multi-sig/P2SH addresses, proposing multi-sig
spends, bundling meta-data needed for lite/offline nodes, aggregating
signatures, and any other details.
When I start multisig integration into Armory (very soon!) I'll write a
list of requirements for the new format/process and post it here for a
wider discussion. Certainly, if the payment protocol can already handle
all this, that would be awesome.
-Alan
On 03/10/2014 08:04 PM, kjj wrote:
> I was trying to use bip10 for multisig and coinjoin, but there was a
> problem with it. I'll have to look back at my notes, but I thought I
> sent you a message about it. And then real life swallowed my bitcoin
> time...
>
> I think the bottom line was that it would be useful in the generic
> case with just one minor change. If there is interest, and it sounds
> like there just may be, I can dust off my notes and see where I left
> it. Probably should do it soon before someone implements it in PB or XML.
>
> Alan Reiner wrote:
>> Then of course I tried to do this with BIP 10
>> <https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
>> Armory implemented offline-transactions two years ago. I got some
>> positive feedback, but no one wanted to help improve it, etc. I
>> guess nobody else was doing it and/or cared at the time. So I
>> continue to use BIP 10 even though it's pretty crappy. I wanted it
>> to be useful for multisig, too, but it has some deficiencies there
>> (it was done when Armory was extremely young and OP_EVAL was still on
>> the table).
>>
>> However, with all this activity, we should start thinking about that
>> and discussing it. Otherwise, I'll just do my own thing again and
>> probably end up with something that fits my own needs, but not anyone
>> else's. Really though, multisig shouldn't require all the same app
>> to work.
>>
>> -Alan
>>
>>
>> On 03/10/2014 01:49 PM, Gavin Andresen wrote:
>>> In my experience, best process for standardizing something is:
>>>
>>> 1) Somebody has a great idea
>>> 2) They implement it
>>> 3) Everybody agrees, "Great idea!" and they copy it.
>>> 4) Idea gets refined by the people copying it.
>>> 5) It gets standardized.
>>>
>>> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
>>> opinion...
>>>
>>>
>>>
>>>
>>> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
>>> <mailto:drak at zikula.org>> wrote:
>>>
>>> I was wondering if there would be merit in a kind of BIP for a
>>> payment protocol using multisig?
>>>
>>> Currently, setting up a multisig is quite a feat. Users have to
>>> exchange public keys, work out how to get the public keys from
>>> their addresses. If one of the parties are not savvy enough, an
>>> malicious party could easily be setup that was 2 of 3 instead of
>>> 2 of 2 where the malicious party generates the multisig
>>> address+script and thus be able to run off with funds anyway.
>>>
>>> It's also terribly complex to generate and keep track of.
>>> There's been a nice attempt at creating an browser interface at
>>> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
>>> the kind of ease with created by the payment protocol. If there
>>> was a BIP then it would go a long way to aiding future usability
>>> of multisig wallet implementations.
>>>
>>> What are your thoughts?
>>>
>>> Drak
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases
>>> and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> <mailto:Bitcoin-development at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Gavin Andresen
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Learn Graph Databases - Download FREE O'Reilly Book
>>> "Graph Databases" is the definitive new guide to graph databases and their
>>> applications. Written by three acclaimed leaders in the field,
>>> this first edition is now available. Download your free book today!
>>> http://p.sf.net/sfu/13534_NeoTech
>>>
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/0f32ee9e/attachment.html>

2023-06-07 17:15:02 CEST

- reply

📅 Original date posted:2014-03-10
📝 Original message:Then of course I tried to do this with BIP 10
<https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki> when
Armory implemented offline-transactions two years ago. I got some
positive feedback, but no one wanted to help improve it, etc. I guess
nobody else was doing it and/or cared at the time. So I continue to use
BIP 10 even though it's pretty crappy. I wanted it to be useful for
multisig, too, but it has some deficiencies there (it was done when
Armory was extremely young and OP_EVAL was still on the table).
However, with all this activity, we should start thinking about that and
discussing it. Otherwise, I'll just do my own thing again and probably
end up with something that fits my own needs, but not anyone else's.
Really though, multisig shouldn't require all the same app to work.
-Alan
On 03/10/2014 01:49 PM, Gavin Andresen wrote:
> In my experience, best process for standardizing something is:
>
> 1) Somebody has a great idea
> 2) They implement it
> 3) Everybody agrees, "Great idea!" and they copy it.
> 4) Idea gets refined by the people copying it.
> 5) It gets standardized.
>
> Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
> opinion...
>
>
>
>
> On Mon, Mar 10, 2014 at 1:39 PM, Drak <drak at zikula.org
> <mailto:drak at zikula.org>> wrote:
>
> I was wondering if there would be merit in a kind of BIP for a
> payment protocol using multisig?
>
> Currently, setting up a multisig is quite a feat. Users have to
> exchange public keys, work out how to get the public keys from
> their addresses. If one of the parties are not savvy enough, an
> malicious party could easily be setup that was 2 of 3 instead of 2
> of 2 where the malicious party generates the multisig
> address+script and thus be able to run off with funds anyway.
>
> It's also terribly complex to generate and keep track of. There's
> been a nice attempt at creating an browser interface at
> coinb.in/multisig <http://coinb.in/multisig> but it still lacks
> the kind of ease with created by the payment protocol. If there
> was a BIP then it would go a long way to aiding future usability
> of multisig wallet implementations.
>
> What are your thoughts?
>
> Drak
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases
> and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140310/2e157654/attachment.html>

2023-06-07 17:14:39 CEST

- reply

📅 Original date posted:2014-03-08
📝 Original message:Note that one of the reasons why this is insecure is because EC point
addition is invertible. EC-scalar multiplication is not, thus why EC
Diffie-Hellman is secure even when this asymmetry exists.
A good cryptosystem doesn't have strange restrictions, like "your public
key can only be public sometimes, but needs to protected like your
private key other times." If you have to worry about things like that,
you're doing it wrong :)
-Alan
On 03/08/2014 05:37 AM, Joel Kaartinen wrote:
> If both parties insist on seeing a hash of the other party's public
> key before they'll show their own public key, they can be sure that
> the public key is not chosen based on the public key they themselves
> presented.
>
> Although, I have to wonder, why not just use multisig?
>
> - Joel
>
> On 08.03.2014 10:51, Edmund Edgar wrote:
>> On 8 March 2014 17:10, Alan Reiner <etotheipi at gmail.com
>> <mailto:etotheipi at gmail.com>> wrote:
>>
>>
>> I create a new keypair, <c_pub> with <c_priv> which I know (it
>> can be any arbitrary key pair). But I don't give you <c_pub>, I
>> give you <b_pub> = <c_pub> minus <a_pub> (which I can do because
>> I've seen <a_pub> before doing this).
>>
>> Sure, I don't know the private key for <b_pub>, but it doesn't
>> matter... because what
>>
>> <b_pub> + <a_pub> = <c_pub> (mine)
>>
>> You have no way to detect this condition, because you don't know
>> what c_pub/c_priv I created, so you can only detect this after
>> it's too late (after I abuse the private key)
>>
>>
>> Thanks Alan and Forrest, that makes sense. So to salvage the
>> situation in the original case, we have to make sure the parties
>> exchange their public keys first, before they're allowed to see the
>> public keys they'll be combining them with.
>>
>> --
>> --
>> Edmund Edgar
>> Founder, Social Minds Inc (KK)
>> Twitter: @edmundedgar
>> Linked In: edmundedgar
>> Skype: edmundedgar
>> http://www.socialminds.jp
>>
>> Reality Keys
>> @realitykeys
>> ed at realitykeys.com <mailto:ed at realitykeys.com>
>> https://www.realitykeys.com
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/eb6e7e08/attachment.html>

2023-06-07 17:14:37 CEST

- reply

📅 Original date posted:2014-03-08
📝 Original message:On 03/08/2014 01:55 AM, Edmund Edgar wrote:
> On 4 March 2014 14:07, Odinn Cyberguerrilla
> <odinn.cyberguerrilla at riseup.net
> <mailto:odinn.cyberguerrilla at riseup.net>> wrote:
>
> Nothing is safe.
>
>
> This is true. To rephrase, imagine I gave you an ECC public key
> <ed_pub>, you gave me back a public key <odinn_pub> of your own
> devising, then I paid some money to the address resulting from
> add_pubkeys(<ed_pub>,<odinn_pub>) [1]. Can anyone either:
>
> a) Think of a way that Odinn could make an <odinn_pub> such that they
> could spend the resulting money without having <ed_priv>.
> b) Opine, somewhat knowledgeably, that this probably wouldn't be an
> easy thing to do, and they wouldn't be alarmed to see people running
> software that did this kind of thing.
>
> [1] https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173
Consider that I see your public key <a_pub> before I create and send you
my public key <b_pub>.
I create a new keypair, <c_pub> with <c_priv> which I know (it can be
any arbitrary key pair). But I don't give you <c_pub>, I give you
<b_pub> = <c_pub> minus <a_pub> (which I can do because I've seen
<a_pub> before doing this).
Sure, I don't know the private key for <b_pub>, but it doesn't matter...
because what
<b_pub> + <a_pub> = <c_pub> (mine)
You have no way to detect this condition, because you don't know what
c_pub/c_priv I created, so you can only detect this after it's too late
(after I abuse the private key)
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140308/7cfbe3a0/attachment.html>

2023-06-07 17:13:22 CEST

- reply

📅 Original date posted:2014-02-12
📝 Original message:Agreed. I'm not suggesting that malleability shouldn't be fixed or isn't a
problem. I would love to be able to leverage chained TX for Bitcoin
contracts. But that in its current state it doesn't have to be complicated
to deal with it.
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.
Sent from my overpriced smartphone
On Feb 12, 2014 11:38 AM, "Allen Piscitello" <allen.piscitello at gmail.com>
wrote:
> While that solution does work for many use cases, it does make it much
> harder to do anything needing chained transactions. Granted, this is the
> short term solution for current implementations, but having a transaction
> identifier that does not change does open up other use cases.
>
> For example, Alice wants to send coins to a multisignature address with
> Bob, such that both parties are required to spend the coins. Alice also
> requires for Bob to send coins to this address as well before they will
> proceed. Alice cannot guarantee that Bob will cooperate (and vice versa),
> so before she broadcasts the transaction to send to A+B, she sends Bob a
> transaction that spends her incoming transaction back to herself, but has a
> time lock of far into the future. Bob signs this, returns it to Alice, and
> she broadcasts her funding transaction. At this point, Bob disappears,
> loses his key, or just decides to spite Alice and her coins are locked.
> Since she has a refund transaction, she can broadcast it in a month and
> get her coins back. Except her funding transaction has been modified such
> that the txhash is different, so her refund is now invalid. She would need
> Bob to issue a new refund as soon as her funding transaction hits the
> blockchain if it is modified, which defeats the point of the trustless
> refund transaction.
>
> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if wallets are able to properly identify the status of it's
> transactions. Obviously this is a difficult problem to solve and cannot be
> implemented without breaking changes, but it would be a nice goal to be
> able to completely remove malleability. There are other important use
> cases where having a unique identifier just for internal accounting is
> insufficient.
>
> -Allen
>
>
> On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi at gmail.com> wrote:
>
>> I think the solution is simply to encourage Bitcoin software developers
>> to design their software to use this static ID, instead of the full
>> transaction hash. If MtGox had talked those IDs instead of the TX ID,
>> their software would've correctly identified the mutated transactions and
>> there would be no problem.
>>
>> Armory is slightly different, since it doesn't deal with the same stuff
>> as exchanges do. But it didn't have any problems with malleability because
>> it doesn't track anything by ID, it only pays attention to whether inputs
>> and outputs are related to your wallets. It's not necessarily hard to do
>> it this way, people just have to be aware of it.
>>
>> -Alan
>>
>> Sent from my overpriced smartphone
>> On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com>
>> wrote:
>>
>>> Instead of trying to remove the possibility of transaction
>>> malleability, would it make sense to define a new, "canonical
>>> transaction hash/ID" (cTxID), which would be a hash of the part of the
>>> transaction data which we know is not malleable, and have clients use
>>> this cTxID internally, thus making the traditional transaction hash
>>> irrelevant for a client to function correctly?
>>>
>>> We already have a non-malleable transaction hash: the hash that is
>>> signed, ie. the transaction with each scriptSig replaced by the
>>> scriptPubKey it redeems. This could be the cTxID.
>>>
>>> Or is this simply a too fundamental change to the way bitcoin-qt (and
>>> all other clients) work in order to be feasible?
>>>
>>> As far as I can see, it completely solves the issue of not having a
>>> canonical ID for a transaction, but it also increases the
>>> computational requirements for a node. For one, as far as I can see,
>>> it requires the node to index all transactions, because in order to
>>> calculate a cTxID, it would be necessary to fetch all transactions
>>> referred to by the transaction in question, in order to pull in the
>>> scriptPubKeys that are redeemed.
>>>
>>>
>>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
>>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
>>> >> Hello all,
>>> >>
>>> >> it was something I planned to do since a long time, but with the
>>> >> recent related issues popping up, I finally got around to writing a
>>> >> BIP about how we can get rid of transaction malleability over time.
>>> >>
>>> >> The proposed document is here: https://gist.github.com/sipa/8907691
>>> >>
>>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
>>> >> they require modifications to wallet software (Bitcoin Core 0.9 and
>>> >> BitcoinJ already implement it, though) and potentially invalidate some
>>> >> script functionality. However, these new rules remain optional and
>>> >> controlled by an nVersion increase.
>>> >>
>>> >> Comments please!
>>> >
>>> > You should probably add making CHECKMULTISIG require the dummy value to
>>> > be exactly equal to OP_FALSE; verifying that in the transaction itself
>>> is
>>> > laborious. A more subtle example is we may want both CHECKSIG and
>>> > CHECKMULTISIG to fail the transaction if the signature is invalid but
>>> > not exactly equal to OP_FALSE; some transaction forms are significantly
>>> > more compact if you can have failed signatures, but that's a source of
>>> > malleability. (are there counter examples people can think of?)
>>> >
>>> >
>>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
>>> > malleability when we have no solid idea if ECC signatures are or are
>>> not
>>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability
>>> is
>>> > all we've got it could be ugly if a break is found. Similarly, we may
>>> > find we missed something, or some needed change makes the malleability
>>> > rules difficult to work with for some new script type that is required.
>>> >
>>> > I'd rather see a new CHECKSIG mode for the case where malleability
>>> > absolutely must be eliminated - certain multi-party protocols - and fix
>>> > wallet software instead. (the malleability problems people see are
>>> > closely related to inability to handle double-spends and reorgs) But I
>>> > can easily see that being an impossible goal engineering wise...
>>> >
>>> > --
>>> > 'peter'[:-1]@petertodd.org
>>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Managing the Performance of Cloud-Based Applications
>>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> > Read the Whitepaper.
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Android apps run on BlackBerry 10
>>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>>> Get your Android app in front of a whole new audience. Start now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience. Start now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/aab9621c/attachment.html>

2023-06-07 17:13:21 CEST

- reply

📅 Original date posted:2014-02-12
📝 Original message:I think the solution is simply to encourage Bitcoin software developers to
design their software to use this static ID, instead of the full
transaction hash. If MtGox had talked those IDs instead of the TX ID,
their software would've correctly identified the mutated transactions and
there would be no problem.
Armory is slightly different, since it doesn't deal with the same stuff as
exchanges do. But it didn't have any problems with malleability because it
doesn't track anything by ID, it only pays attention to whether inputs and
outputs are related to your wallets. It's not necessarily hard to do it
this way, people just have to be aware of it.
-Alan
Sent from my overpriced smartphone
On Feb 12, 2014 10:15 AM, "Rune Kjær Svendsen" <runesvend at gmail.com> wrote:
> Instead of trying to remove the possibility of transaction
> malleability, would it make sense to define a new, "canonical
> transaction hash/ID" (cTxID), which would be a hash of the part of the
> transaction data which we know is not malleable, and have clients use
> this cTxID internally, thus making the traditional transaction hash
> irrelevant for a client to function correctly?
>
> We already have a non-malleable transaction hash: the hash that is
> signed, ie. the transaction with each scriptSig replaced by the
> scriptPubKey it redeems. This could be the cTxID.
>
> Or is this simply a too fundamental change to the way bitcoin-qt (and
> all other clients) work in order to be feasible?
>
> As far as I can see, it completely solves the issue of not having a
> canonical ID for a transaction, but it also increases the
> computational requirements for a node. For one, as far as I can see,
> it requires the node to index all transactions, because in order to
> calculate a cTxID, it would be necessary to fetch all transactions
> referred to by the transaction in question, in order to pull in the
> scriptPubKeys that are redeemed.
>
>
> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete at petertodd.org> wrote:
> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
> >> Hello all,
> >>
> >> it was something I planned to do since a long time, but with the
> >> recent related issues popping up, I finally got around to writing a
> >> BIP about how we can get rid of transaction malleability over time.
> >>
> >> The proposed document is here: https://gist.github.com/sipa/8907691
> >>
> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as
> >> they require modifications to wallet software (Bitcoin Core 0.9 and
> >> BitcoinJ already implement it, though) and potentially invalidate some
> >> script functionality. However, these new rules remain optional and
> >> controlled by an nVersion increase.
> >>
> >> Comments please!
> >
> > You should probably add making CHECKMULTISIG require the dummy value to
> > be exactly equal to OP_FALSE; verifying that in the transaction itself is
> > laborious. A more subtle example is we may want both CHECKSIG and
> > CHECKMULTISIG to fail the transaction if the signature is invalid but
> > not exactly equal to OP_FALSE; some transaction forms are significantly
> > more compact if you can have failed signatures, but that's a source of
> > malleability. (are there counter examples people can think of?)
> >
> >
> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about
> > malleability when we have no solid idea if ECC signatures are or are not
> > malleable on a fundemental level; if "whack-a-mole" anti-malleability is
> > all we've got it could be ugly if a break is found. Similarly, we may
> > find we missed something, or some needed change makes the malleability
> > rules difficult to work with for some new script type that is required.
> >
> > I'd rather see a new CHECKSIG mode for the case where malleability
> > absolutely must be eliminated - certain multi-party protocols - and fix
> > wallet software instead. (the malleability problems people see are
> > closely related to inability to handle double-spends and reorgs) But I
> > can easily see that being an impossible goal engineering wise...
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
> >
> >
> ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140212/5c046193/attachment.html>

2023-06-07 17:11:54 CEST

- reply

📅 Original date posted:2014-01-13
📝 Original message:On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch. You can put your root key on a business card if you want. Then
>> when someone wants to pay you, you simply give them the multiplier and
>> root key (they already have the root key, but should verify). The
>> multiplier does not reveal the chaincode, thus keeping it private, but
>> it does allow them to confirm that the final address they are paying is
>> derived from that root key they know belongs to you ("Please pay address
>> X; oh btw, X=rootKey*mult").
>>
>> You can /choose/ to reveal that a given payment address is linked to
>> your root key without any compromise of privacy. Or you can choose to
>> ignore it and just give them a bare address the old way and still
>> maintain privacy. What advantages does "stealth addresses" have over
>> this scheme? You could extend it using some kind of deterministic
>> sub-branching and/or ECDH to create multiple payment addresses without
>> querying the payee.
>
> Basically stealth addresses *are* your scheme, using the blockchain as a
> low or even no overhead communication channel for the payor to give the
> payee that multiplier without bidirectional communication.
>
> In the business card example I can't easily take your business card and
> just send you some money without that transaction being linked to public
> information. (your business card)
It's not public. When I say "please pay me" I also say "use this
multiplier". The multiplier isn't published, and it's not publicly
discoverable without my wallet (or access to my email). The address
remains private between you and me. As you said, it could be
discoverable if the email is discoverable, but I'm not seeing how how
critical that really is.
There's a lot of complexity around this constraint (possibly involving
new/secondary private keys, extra outputs, relying on change outputs,
and/or using 3rd parties to help look for transactions). I'm not
convinced that what is being gained is really worth that extra complexity.
By contrast, what I proposed, that does require sending sending the
payer a multiplier once, is easy to implement in any BIP 32 wallet,
doesn't require any special address formats, and achieves 98% of the
same benefits without any special computation. I guess I'm just not
convinced that it's really necessary for people to be able to send
others payments without contacting them (and/or hiding the evidence a
payment was made even if they communications were discovered).
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140113/d7ebb30c/attachment.html>

2023-06-07 17:11:52 CEST

- reply

📅 Original date posted:2014-01-13
📝 Original message:How is this different from the proposal I have made?
You distribute the root public key (but not chaincode!) of a BIP32
branch. You can put your root key on a business card if you want. Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the root key, but should verify). The
multiplier does not reveal the chaincode, thus keeping it private, but
it does allow them to confirm that the final address they are paying is
derived from that root key they know belongs to you ("Please pay address
X; oh btw, X=rootKey*mult").
You can /choose/ to reveal that a given payment address is linked to
your root key without any compromise of privacy. Or you can choose to
ignore it and just give them a bare address the old way and still
maintain privacy. What advantages does "stealth addresses" have over
this scheme? You could extend it using some kind of deterministic
sub-branching and/or ECDH to create multiple payment addresses without
querying the payee.
I had planned to implement this system and push for people to accept it
because I don't see any downsides to it. It can easily be integrated
into a WoT (with signed root keys), or CA system piggybacking on SSL.
-Alan
On 01/13/2014 02:44 PM, Drak wrote:
> On 13 January 2014 19:40, Roy Badami <roy at gnomon.org.uk
> <mailto:roy at gnomon.org.uk>> wrote:
>
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
>
>
> My thoughts exactly.
>
> Drak
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140113/85d58fe9/attachment.html>

2023-06-07 17:03:36 CEST

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
> Hi Alan,
>
>> “BIP 32 does not prescribe a way to use multiple chains like you described
>> with the convenient type-2 derivation (though we could create a variant
>> that does)”
> What do you think is missing from BIP32 for this? A wallet creates a
> child-node using the public / type-2 CDF, hands out the PubKey/ChainCode,
> and then generally expects transactions to come in starting at /0 and
> incrementing monotonically.
>
You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting. I
disagree. I am okay with using different wallets for different parties
*/if the user wants to/*. But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services. And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.
BIP 32 already specifies how to use the first three tree levels:
M/i/j/k, i~wallet, j~Internal/External, k~address. The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet. So it's not
"free" to create new wallets unless we redefine how the levels work.
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
-- Do these extra wallet chains behave as different wallets, or
sub-wallets?
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism? Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.
All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet. With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity. If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets. But it's not the only way.
To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/350ab33e/attachment.html>

2023-06-07 17:03:35 CEST

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
> If you have two parties who want to form a persistent relationship, by
> exchanging and verifying public keys beforehand, then I think the
> canonical way to do this with BIP32 is for the parties to exchange
> PubKey and *ChainCode*.
>
> I don't understand the use case for handing out individual
> multipliers, if what you desire is a persistent relationship. If each
> party dedicates a child-wallet for receiving coins, and saves a
> PubKey/ChainCode for sending coins, the two parties can transaction
> securely forever without ever exchanging any more information, and
> without any address reuse.
>
> I think ideally, the default behavior is that wallets always dedicate
> a new child node {PubKey, ChainCode} to each party they transact with.
> At the presentation layer, you have a "contact" and each contact has a
> transaction history. You can send coins to a contact at any time, and
> internally the wallet picks the next address in their sequence. Any
> funds received on pubkeys from contact's sequence are attributed to
> that contact. The wallet can organize the contacts, and roll-up the
> transaction history into 'ledgers' and 'balances' however they want --
> it could be based on the underlying BIP32 hierarchy or perhaps not.
> The cost of watching large a number of pubkeys, even if you 'look
> ahead' 100 pubkeys for each contact, is relatively small versus the
> benefits.
>
>
What you just described is complimentary to what I am proposing. There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances. BIP 32 does not prescribe a way to
use multiple chains like you described with the convenient type-2
derivation (though we could create a variant that does). And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory.
So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts. For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity. If I
don't want that, I use your method. If I do want that, I use my
method. Given its simplicity, I don't know why both can't be options.
Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/bc4628e8/attachment.html>

2023-06-07 17:03:33 CEST

- reply

📅 Original date posted:2013-06-20
📝 Original message:On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> which could involve proving something to a third party that has not seen
>> the communication between payer and payee.
> OK - I think I follow now. So a third-party who does not see any of the
> communication between the payer and payee only knows the HASH160. Let's say
> the payee denies receipt of the funds....
>
> It's easy to prove what public key it was sent to (it's the preimage), but
> you can't prove the parent of that public key. You can provide any number of
> ParentPubKey * Multiplier that could have been used, so the 3rd party is
> unconvinced by a "matching" ParentPubKey * Multiplier.
>
> However, if you calculated the destination using: PubKeyParent *
> HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
> PubKeyParent and Multiplier (or Addend) that produces the destination
> address, you've proven the payment is in fact spendable by PubKeyParent, and
> they can't deny receipt. Very cool.
>
> Sorry for "echoing" this back, it took me a little while to work it out, so
> I thought I'd write it down. Hope I got it right...
>
> If you give {PubKey, ChainCode} you do get this feature. If you give
> {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
> having plausible deniability.
>
> If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
> could give HMAC(cpar, i) instead of Addend, and then you would get this
> feature; a way to 'skip down' a level in the wallet hierarchy, keep the
> 'chain of custody' so to speak back to the ParentPubKey intact, without
> having to disclose the ChainCode. Meh...
>
>
I agree, if we used Timo's suggestion, that seems to clean up the
remaining uncertainties with this recommendation. I'm not convinced
those uncertainties matter in this situation, where there is no question
about the parent public key. That is the part of the process that was
already verified, per my previous examples. But certainly, for this to
be more versatile it would need that.
If I modify my request to match Timo's recommendation, then it loses the
benefit of being a simple, non-disruptive extension of BIP 32. I'm not
fond of deviating from BIP 32, as it kind of defeats one of the benefits
of BIP 32: standardization. And I'm not inclined to make an
Armory-specific wallet variant.
But I can't tell if the benefits are lost on you, or you just don't
think they are worth it (or I'm overstating them). I'm strongly opposed
to bring extra wallets/chains into this equation /*just*/ to get a
benefit that can be had with a simple alternative encoding. This isn't
a question of which is better, it's a matter of recognizing that both
forms have usefulness and should both be supported.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130620/a9b89205/attachment.html>

2023-06-07 17:03:30 CEST

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 10:25 AM, Timo Hanke wrote:
> Since you mention to use this in conjunction with the payment protocol,
> note the following subtlety. Suppose the payer has to paid this address
> called "destination":
>> Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
>> checksum)
> Also suppose the payee has spent the output, i.e. the pubkey
> corresponding to "destination", which is PubKeyParent * Multiplier[i],
> is publicly known. Then anybody can (in retrospect) create arbitrary
> many pairs {PublicKeyParent, Multiplier} (in particular different
> PublicKeyParent) that lead to the same "destination".
>
> Depending on what you have in mind that the transaction should "prove"
> regarding its actual receiver or regarding the receiver's PubKeyParent,
> this could be an unwanted feature (or it could be just fine). If it is
> unwanted then I suggest replacing
> PubKeyParent * Multiplier[i] by
> PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
> which eliminates from the destination all ambiguity about PubKeyParent.
>
> This modification would not be directly compatible with BIP32 anymore
> (unfortunately), but seems to be better suited for use in conjunction
> with a payment protocol.
>
> Timo
It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem: spoofing a relationship between
a target public key and one that you control. For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to "prove" [maliciously] is related to PubB, then you have
to find the multiplier, M that solves: M*PubC = PubB. That's a
discrete logarithm problem.
I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys. It's an interesting
point, and there may be a reason to be concerned about it. Though, I
don't see it yet.
-Alan

2023-06-07 17:03:29 CEST

- reply

📅 Original date posted:2013-06-19
📝 Original message:On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
>
> Generally in favour of hierarchical deterministic wallets.
>
> Will this new style of address make it into the block chain? I'd be
> less keen on that.
>
> I'm finding BIP0032 quite hard to read right now, but perhaps that's
> because I'm less familiar with the material than some. However,
> there's little things like it never actually defines a deterministic
> wallet in the Abstract. But, I'll keep trying to understand and see
> if I can use the test vectors.
>
>
>
This has nothing to do with the blockchain. This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address. The same thing ends up in the
blockchain, either way.
Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)
I can always give you version #1, and that's what everyone does right
now. Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130619/1038df24/attachment.html>

2023-06-07 17:03:27 CEST

- reply

📅 Original date posted:2013-06-18
📝 Original message:_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a "Wallet ID" and "One-time payment" code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party. For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.
_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed. I'm calling
it "wallet-linkable" addresses, which would be an optional second form
for sending someone your address. With BIP 32, the address is computed
by the payee (the person sending the address to receive money):
Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)
What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own. This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same. Remember, this is _optional_ for the
person providing the address.
One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the "chaincode" (I think Pieter started
calling it the "tweak"). It is derived from the chaincode but doesn't
reveal it. Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode. But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet. It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.
*_Use Cases:_*
(1) So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner. After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it. If the payee's system is compromised and address
is replaced, the address received by the payer won't validate. This
doesn't help if the side sending the money is compromised.
(2) When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}. When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match. If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so.
_*Downsides:*_
Multi-sig/P2SH - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software. Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses. The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script). The blockchain still benefits from the "compression" of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee. But it
may not /really/ be a problem, given the benefits. It might just be
slightly longer strings to exchange during initialization and for each
transaction.
I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130617/d52177a4/attachment.html>

2023-06-07 12:44:52 CEST

- reply

📅 Original date posted:2012-12-03
📝 Original message:These are all valid points. I hadn't really thought much about this point
until you all just brought it up. The reason I so quickly spout off that
phrase, is that I endlessly get requests from Armory users to implement
more anonymity-based features. When I say there are bigger priorities,
they suggest that "anonymity" is a core benefit of Bitcoin and I should be
supporting it. I'm not against anonymity, and I most certainly favor
privacy, but my goal was to produce a versatile client, not one focused on
any one aspect -- there are plenty of people who use it for other reasons
than anonymity.
However, I do like Greg's comment about "attacks" against a
blind-dust-inclusion algorithm, and suggestion to maintain a clustering of
already-linked addresses. That's not terribly difficult to do with the
transaction history in hand, and it could increase how often the logic
triggers. I suppose these hardcore SD players probably have a lot of
one-satoshi outputs that could use vacuuming...
On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair <stephen at bitpay.com> wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn <mike at plan99.net> wrote:
>
>> Second thing, it's best to carefully separate "anonymity" from
>> "privacy". Privacy is supposed to be a feature of the system (it says
>> so in Satoshis paper) because people demand it. If I loan a tenner to
>> my friend and he is able to find out what I earned last month, then
>> that trade was neither anonymous nor private. In this case I want
>> privacy but anonymity isn't useful. Mixing up anonymity with privacy
>> is not only a public relations problem, but can lead to confusion from
>> users when they, eg, try and buy Bitcoins from an exchange and are
>> asked to provide ID proofs.
>
>
> I would like to second this point...privacy is essential because the
> market demands it. If Bitcoin doesn't do it well (and I would argue that
> it doesn't today), then eventually a competitor to Bitcoin will do it
> better and that would be the beginning of the end for Bitcoin. Debates
> about whether it was or wasn't a core feature are pointless.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/cc823863/attachment.html>

2023-06-07 12:44:42 CEST

- reply

📅 Original date posted:2012-12-03
📝 Original message:On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
> (1) Make client software aggressive about sweeping up dust inputs:
> "Any time a transaction is created that has change keep adding in
> extra inputs— smallest to largest— until an additional one would
> increase the cost of the transaction by 0.0001 BTC or more" — the only
> major complication is doing this without concurrently harming privacy
> which is why it's not done yet in the reference client.
FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions. However, there's enough conditions on it, that
I don't know how often it triggers. Recommendations are welcome for how
to improve it.
Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly. Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this. (reorganized the code
<https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279>
recently, and must have fell through the cracks).
Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior. After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to "opt-out" of that logic if user cares. I think
most users don't actually care...
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121203/d0a9abab/attachment.html>

2023-06-07 12:21:16 CEST

- reply

📅 Original date posted:2012-07-09
📝 Original message:I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that "clients" page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt client, and a
link of where to find more information (i.e. the wiki). I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.
We either have to have a "czar" who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call. Or we just move it to another page that is less
strictly controlled and where these things matter less. Trying to gain
consensus among an amalgamation of developers all with competing priorities
and "products" is a terrible way to try to agree on stuff.
-Alan
On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> > JS randomisation is bad. People shouldn't need JS to view a webpage.
>
> JS randomization doesn't imply needing JS to view the page. It implies
> needing JS to see it in random order. You could also combine it with
> the server-side randomization if you care about non-js being non
> random, though I don't think it matters.
>
> As others have pointed out I don't generally think the randomization
> is good in principle, but if its done it should at least achieve its
> goals.
>
> > Only you have a problem with this page. I don't see why Bitcoin-Qt needs
> to be first either when it dominates the front page. It is perfectly fine
> as it is.
>
> I'll let other people speak for themselves, but I did consult others
> before reverting your last batch of changes.
>
> More generally, we have pull requests in order to get some peer review
> of changes. Everyone should use them except for changes which are
> urgent or trivially safe. (Presumably everyone with access knows how
> to tell if their changes are likely to be risky or controversial)
>
> > You are not a developer of any alternative clients, and this is a
> webpage for Bitcoin clients. I have made a change to remove a source of
> disputes, and make the process more fair and equal. Your suggestion to
> remove the clients page is your bias towards thinking that there should be
> only one Bitcoin client that everyone uses (the one which you contribute
> towards).
>
> I'm strongly supportive diversity in the Bitcoin network, and some alt
> client developers can speak to the positive prodding I've given them
> towards becoming more complete software. If I've said anything that
> suggests otherwise I'd love to be pointed to it in order to clarify my
> position.
>
> Unfortunately none of the primary alternatives are yet complete, the
> network would be non-function if it consisted entirely of multibit or
> electrum nodes (and as you've noted armory uses a local reference
> client as its 'server'). The distinction between multiple kinds of
> clients in terms of security and network health are subtle and can be
> difficult to explain even to technical users and so until something
> changes there the reference client needs to be the option we lead
> with. People should us it unless their use-case doesn't match. When it
> does they'll know it and they'll be looking. We don't need to make one
> of those recommendations a primary option.
>
> I like the proposals of moving this stuff to the Wiki as the wiki
> already contains tons of questionable (and sometimes contradictory)
> advice and so there is less expectation that placement there implies
> any vetting.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120709/664e705e/attachment.html>

2023-06-07 12:09:55 CEST

- reply

📅 Original date posted:2012-05-25
📝 Original message:I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed, especially
if it requires spontaneous super-majority-of-nodes acceptance. I think
it's gotta be based on the block itself and each nodes' own info.
If you could spontaneously get all miners to agree not to build off of
anti-social blocks (however that is defined) , it would have a chance of
making a difference, but individual miners would have an advantage
building off the antisocial block because they only need to produce one to
create the longest chain (and collect reward) while the miners following
the rules need two blocks.
--Sent from my overpriced smartphone
On May 25, 2012 3:48 AM, "Christian Decker" <decker.christian at gmail.com>
wrote:
> How about a simple proof of work test? This one though does not ask for
> CPU work but asks the miner for a random old transaction. If the miner
> really stores the entire blockchain he will not have any problem answering
> to that getdata request, whereas a botnet would have to ask someone else
> for it, which could be detected if the response time deviates too much from
> what has been previously measured (compare it against getdata for the block
> they advertise). It's not perfect but it allows an estimate of whether it
> is a chainless miner.
>
> Regards,
> Chris
> --
> Christian Decker
>
>
>
> On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik <jgarzik at exmulti.com> wrote:
>
>> On Thu, May 24, 2012 at 8:57 PM, Luke-Jr <luke at dashjr.org> wrote:
>> > Block times are not accurate enough for that.
>>
>> The times in your log are very accurate, assuming your system clock is
>> remotely accurate.
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120525/856b88ab/attachment.html>

2023-06-07 12:07:39 CEST

- reply

📅 Original date posted:2012-05-03
📝 Original message:I want to follow up on BIP 21 (URI scheme), which I have recently
implemented in Armory and I have become a huge fan of it. But I've got
a couple gripes:
*(1) *What is the status & plans for supporting "bitcoin:" URIs in the
Satoshi client? My understanding is that it currently creates URIs, but
does *not* register itself with the OS to handle such links. Is this
accurate? This seems like a very high-value feature, and I'd recommend
that we consider it a priority -- I can't think of any other upgrade
that can improve usability so dramatically on the desktop.
After implementing it all in Armory, I wrote up a walk-thru
<https://bitcointalk.org/index.php?topic=79010.msg879804#msg879804>
recounting how I did the OS-registration in Windows and gnome-based *nix
systems. Perhaps it can give the Bitcoin-Qt devs a jumpstart on getting
it implemented. (and then I can get feedback about doing for generic
Linux and Mac/OSX)
*(2) *I need to understand better what the intentions were behind
"label=" and "message=". The way I understand it is that Bitcoin-Qt
uses and stores only address-labels, and no other transactional info is
stored in the wallet. As such, the "message=" field would be displayed
to the user when a "bitcoin:" link is clicked, but that message wouldn't
be saved anywhere.
However, I think, especially if a new wallet format is in the works,
that both should be supported: "Address Labels" *and *"Transaction
Labels". The real difference is that merchants can include things
Order#, purchase information, etc, in the "message" field, and then put
only their business name in the "label" field. This means that when the
user is looking at their address book, they see just the owners of the
addresses. When they look at the transaction ledger/history, they see a
full list of everything they purchased, prices, contact info, etc. The
distinction is much more important for persistent addresses, but still
important.
This is exactly how I did it in Armory, but if Bitcoin-Qt won't do it
that way, I should be promoting all important information be jammed into
the "label" field.
*(3) *How are the other clients implementing this? Do you make any
distinction between "label" and "message"?
-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120503/6ead9661/attachment.html>

2023-06-07 12:06:48 CEST

- reply

📅 Original date posted:2012-05-02
📝 Original message:I think it's perfectly reasonable to debate ordering. I personally don't
think Armory should be up front, because it's not intended for beginners.
How's that for honesty? I don't think anyone is trying to game the system
right now, I think we're trying to come up with a reasonable mechanism for
appealing to new users and get the community more connected. And make
sure everyone understands the system.
On the other hand, perhaps it's better to take the acceptable 80% solution,
and revise it over time...
Amir, I don't have access to the page. I've never been able to view it.
Changing my hosts file doesn't seem to do anything. Can you just forward
me the text? I'll send you an approval email.
On Wed, May 2, 2012 at 3:43 PM, Amir Taaki <zgenjix at yahoo.com> wrote:
> This discussion about ordering is absolutely retarded. Once the list fills
> up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
> first and the others ordered however. That was nobody can try to game the
> system (it remains unexploitable).
>
> If there are no objections, then I am going to merge this branch. The
> forum thread is divulging into a mess all over the place, and this
> conversation can go on forever discussing the silly fine details:
>
> http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
> You suggest creating something new for your hackerspace, like a
> bikeshed. But now all anyone will discuss is its colour. No bikeshed
> will be built.
>
> Armory & MultiBit, are you OK with that description? I will check with
> ThomasV about Electrum.
>
>
> ________________________________
> From: Gary Rowe <g.rowe at froot.co.uk>
> To: "bitcoin-development at lists.sourceforge.net" <
> bitcoin-development at lists.sourceforge.net>
> Sent: Wednesday, May 2, 2012 8:34 PM
> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>
>
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
> This is like the most annoying thing about email. Often with group emails,
> we'll be having a conversation then someone will click reply instead of
> group reply and the convo will go on for a while. Eventually I'll realise
> the persons are missing and add them back in.
> >
> >On Yahoo mail (which I use for spam/mailing lists), to do reply all
> involves clicking a tab, scrolling down and clicking Reply All. Normally I
> instead go through the steps of reply, delete To, re-enter bitco... select
> drop down, click send.
> >
> >Anyone know how to make reply all the default in mutt? And how can I
> exclude it from re-including my own email when I do a group reply so I
> don't get the same email again.
> >
> >
> >
> >
> >----- Original Message -----
> >From: Jeff Garzik <jgarzik at exmulti.com>
> >To: grarpamp <grarpamp at gmail.com>
> >Cc: bitcoin-development at lists.sourceforge.net
> >Sent: Wednesday, May 2, 2012 7:29 PM
> >Subject: Re: [Bitcoin-development] new bitcoin.org clients page
> >
> >
> >On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
> >>> Try "Reply to All"
> >>
> >> That puts the sender in 'to' and list in 'cc',
> >> which dupes to the sender and eventually
> >> blows out the to and cc lines as everyone
> >> chimes in and doesn't trim. 'reply to' solves
> >> most of that. assuming the list sw can do it.
> >
> >"Reply-To" Munging Considered Harmful
> >http://www.unicom.com/pw/reply-to-harmful.html
> >
> >
> >
> >--
> >Jeff Garzik
> >exMULTI, Inc.
> >jgarzik at exmulti.com
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
>
> >------------------------------------------------------------------------------
> >Live Security Virtual Conference
> >Exclusive live event will cover all the ways today's security and
> >threat landscape has changed and how IT managers can respond. Discussions
> >will include endpoint security, mobile security and the latest in malware
> >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >_______________________________________________
> >Bitcoin-development mailing list
> >Bitcoin-development at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/08c0ebe1/attachment.html>

2023-06-07 12:06:37 CEST

- reply

📅 Original date posted:2012-05-02
📝 Original message:I'm not sure what "designed for occasional use" means. Many users of
other clients use them exclusively without touching other clients. Armory
is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
I'm sure the other clients are the same.
Instead, I think that line would be replaced by a blurb about the target
audience. "Designed for Advanced Users". "Designed for Quick Setup and
Instant usability".
Btw, Armory now has full installers for both Windows and Linux
(Ubuntu/Debian), with uninstallers and automatic URI registration
On Wed, May 2, 2012 at 3:34 PM, Gary Rowe <g.rowe at froot.co.uk> wrote:
> How about keeping it simple?
>
> Bitcoin-Qt
> * Requires the entire blockchain
> * Standalone client
> * Designed for continuous operation
> * Available for Windows, Mac, Linux with installer
> * Developed in C
> * Website: https://bitcoin.org
>
> MultiBit
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use
> * Available for Windows, Mac, Linux with installer
> * Developed in Java
> * Website: http://multibit.org
>
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
> * Designed for occasional use
> * Available for Windows (64-bit only), Mac, Linux (self-build)
> * Developed in Python
> * Website: http://bitcoinarmory.com/
>
> Electrum
> * Requires no blockchain
> * Dependent client of Bitcoin-Qt (on server)
> * Designed for occasional use
> * Available for Windows, Linux (self-build)
> * Developed in Python
> * Website: http://ecdsa.org/electrum/
>
> Bitcoin Wallet (Android client)
> * Requires a reduced blockchain
> * Standalone client
> * Designed for occasional use on mobile
> * Available for Android only
> * Developed in Java
> * Website:
> https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en
>
>
> On 2 May 2012 20:25, Amir Taaki <zgenjix at yahoo.com> wrote:
>
>> This is like the most annoying thing about email. Often with group
>> emails, we'll be having a conversation then someone will click reply
>> instead of group reply and the convo will go on for a while. Eventually
>> I'll realise the persons are missing and add them back in.
>>
>> On Yahoo mail (which I use for spam/mailing lists), to do reply all
>> involves clicking a tab, scrolling down and clicking Reply All. Normally I
>> instead go through the steps of reply, delete To, re-enter bitco... select
>> drop down, click send.
>>
>> Anyone know how to make reply all the default in mutt? And how can I
>> exclude it from re-including my own email when I do a group reply so I
>> don't get the same email again.
>>
>>
>>
>> ----- Original Message -----
>> From: Jeff Garzik <jgarzik at exmulti.com>
>> To: grarpamp <grarpamp at gmail.com>
>> Cc: bitcoin-development at lists.sourceforge.net
>> Sent: Wednesday, May 2, 2012 7:29 PM
>> Subject: Re: [Bitcoin-development] new bitcoin.org clients page
>>
>> On Wed, May 2, 2012 at 12:58 PM, grarpamp <grarpamp at gmail.com> wrote:
>> >> Try "Reply to All"
>> >
>> > That puts the sender in 'to' and list in 'cc',
>> > which dupes to the sender and eventually
>> > blows out the to and cc lines as everyone
>> > chimes in and doesn't trim. 'reply to' solves
>> > most of that. assuming the list sw can do it.
>>
>> "Reply-To" Munging Considered Harmful
>> http://www.unicom.com/pw/reply-to-harmful.html
>>
>>
>>
>> --
>> Jeff Garzik
>> exMULTI, Inc.
>> jgarzik at exmulti.com
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120502/af738a5b/attachment.html>

2023-06-07 04:38:58 CEST

- reply

📅 Original date posted:2011-11-12
🗒️ Summary of this message: A user suggests that the point of Bitcoin Improvement Proposals (BIPs) is to collaborate and come up with a good solution before implementation. BIPs should not be a place for armchair designs without corresponding implementation.
📝 Original message:Maybe I'm new to this, but this doesn't make any sense. I thought the
point of the BIP was to collaborate to come up with a good solution.
That's exactly what I want to do before I implement it in my software.
After all, they are "Bitcoin Improvement *Proposals*." It seems like
EXACTLY what a BIP is for... just no one needs/should use it until it
removes the "draft" marking.
As for the protocol on top of it, my BIP was not intended to address
that. It's only proposing how unsigned transactions can be serialized
and users can collect addresses. Whatever system you want to implement
on top of it to exchange the data is up to the developer. My only
motivation is that if the user clicks "Save this proposal to file", that
any client can use the resulting file, just the same way we serialize
any other blockdata that has a consistent representation.
-Alan
On 11/12/2011 11:58 AM, Mike Hearn wrote:
> Please don't create BIPs that don't have any actual implementation
> behind them. Design discussion is fine but the mailing list works for
> that.
>
> If I were going to implement escrow transactions in BitCoinJ it would
> not matter what was written here. I'd just implement the design I
> thought made sense. If that design was later adopted by others it can
> be documented and agreed upon in a BIP, just like a regular RFC.
>
> For what it's worth I would not attempt to send half-valid escrow
> transactions through the p2p network, not even using the overlay
> networks the protocol already supports. A correct escrow protocol
> requires the seller to challenge the dispute mediator with the public
> key to be sure they actually own it, and the simplest way to do that
> is to leverage the existing DNS/EV-SSL infrastructure with a "sign
> this nonce" HTTP request.
>
> BIPs should not be a place for people to come up with armchair
> designs, because a design with no corresponding implementation is
> likely to be full of problems. Let's revisit this once I can install
> some software on my laptop, my server, and a friends server, and do a
> 3-way mediated transaction between them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111112/e36715ff/attachment.html>

2023-06-07 04:35:32 CEST

- reply

📅 Original date posted:2011-10-25
🗒️ Summary of this message: The proposed OP_EVAL tool for multi-signature transactions is optional, and regular OP_CHECKMULTISIG can still be used. It is important to keep the subscripts/mappings in the wallet forever, and there should be an easy way to add such a script/mapping to the wallet.
📝 Original message:On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111025/e630403f/attachment.html>