Andreas Petersson [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-07-17 to 2015-06-20
💬 Posted a total of 15 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:39:23

- reply

📅 Original date posted:2015-06-19
📝 Original message:>m/##'/0'/99'/0'
>
>where 99 is the identifier for, say, counterparty
What is stopping you from using m/44'/9'/a'/c/i as descibed here:
http://doc.satoshilabs.com/slips/slip-0044.html
to avoid having an internal mapping from 9'-> 0' to find out what
blockchain to query, this sounds like it should be trivial for any wallet.

2023-06-07 15:38:58

- reply

📅 Original date posted:2015-06-19
📝 Original message:I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.
0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.
RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.
for any online or automated system, waiting for a handful of
confirmations was always recommended practice.
Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> Retail POS merchants probably should not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several
> blocks deep in the chain. Retail merchants should be requiring a
> co-signature from a mutually trusted co-signer that vows never to sign
> a double-spend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xAA4EDEEF.asc
Type: application/pgp-keys
Size: 998 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/84f25498/attachment.bin>

2023-06-07 15:13:57

- reply

📅 Original date posted:2014-02-24
📝 Original message:Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less fees
using a multisig TX, then this will happen.
eventually dust-limit rules will not be the deciding factor here, since
i suspect block propagation times will have a stronger effect on
effective fees. therefore a slightly larger payload than the biggest
multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
(this is my understanding of how large a 3-of-3 multisig tx can be, plus
1.5 bits encoded in the "n" parameter)

2023-06-07 15:10:19

- reply

📅 Original date posted:2013-12-06
📝 Original message:I know we should all be brainstorming and working on a new fee market.
But fact is, it will still take some time and in the meantime users will
continue to shout insults at us for the high "fixed" fee of 0,1 mBtc.
Even banks sometimes have less fees. (1 of 5 Play Store reviews of
Mycelium seem to mention high fees recently)
My suggestion: until the market is established let's lower the minimum
relay fee per kb to something less. 0,01 mBtc comes to mind. (of course
pulling this number out of thin air)

2023-06-07 15:07:55

- reply

📅 Original date posted:2013-10-25
📝 Original message:> There's no reason the signing can't be done all at once. The wallet
> app would create and sign three transactions, paying avg-std.D, avg,
> and avg+std.D fee. It just waits to broadcast the latter two until it
> has to.
i see several reasons why this is problematic.
So how would that work in a setting where the user signs a transaction
created offline, transmitted via Bluetooth via a one-way broadcast?
does it transmit all 3 tx to the receiver and just hopes they he will do
the "right thing"?
>
> On 10/25/13 5:02 AM, Andreas Petersson wrote:
>>
>>
>>> Worth thinking about the whole ecosystem of wallets involved;
>>> they all have to handle double-spends gracefully to make tx
>>> replacement of any kind user friendly. We should try to give
>>> people a heads up that this is coming soon if that's your
>>> thinking.
>>
>> If there is a situation where wallets are supposed to constantly
>> monitor the tx propagation and recreate their transactions with
>> different fees, this would make a lot of usecases inconvenient.
>> half-offline bluetooth transactions, users with unstable
>> connections, battery power lost, etc, etc. - and last but not least
>> power concerns on hardware wallets on the bitcoincard (tx signing
>> drains a significant amount of power and should therefore only be
>> done once)
>>
>>

2023-06-07 15:07:54

- reply

📅 Original date posted:2013-10-25
📝 Original message:> Worth thinking about the whole ecosystem of wallets involved; they all
> have to handle double-spends gracefully to make tx replacement of any
> kind user friendly. We should try to give people a heads up that this is
> coming soon if that's your thinking.
If there is a situation where wallets are supposed to constantly monitor
the tx propagation and recreate their transactions with different fees,
this would make a lot of usecases inconvenient.
half-offline bluetooth transactions, users with unstable connections,
battery power lost, etc, etc. - and last but not least power concerns on
hardware wallets on the bitcoincard (tx signing drains a significant amount
of power and should therefore only be done once)
-Andreas

2023-06-07 15:06:46

- reply

📅 Original date posted:2013-09-11
📝 Original message:This an excellent idea, because i proposed the same thing previously.
these bip 39 mnemonics are IMO too hard to remember.
using NLP we could generate a gramatically correct sentence out of 128
completely random bits which is possible to remember. information could
be encoded in the selection of words but also in the choice of the
syntax tree.
if i had too much spare time this would be an excellent project.
Am 11.09.2013 00:35, schrieb Mark Friedenbach:
> For a while I've wanted to combine one of these mnemonic code generators
> with an NLP engine to do something like output a short story as the
> passphrase, even a humorous onem with the key encoded in the story
> itself (remember the gist of the story and that's sufficient to
> reconstruct the key).

2023-06-07 15:05:40

- reply

📅 Original date posted:2013-08-19
📝 Original message:I was just reviewing the integration work to integrate the Payment
Protocol into our products. Is there any notion of a standardized
invoice serialisation? If i pay for two Burgers and one Club Mate, how
would my Bitcoin Wallet be able to know that? Right now, i would simply
put that into "memo" and come up with my own serialisation mechanism.
Second, is there a way to communicate acceptance levels of TX
(unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK?
-Andreas

2023-06-07 15:04:31

- reply

📅 Original date posted:2013-07-09
📝 Original message:It particulary worries me that a lot of sites hand over their SSL
private keys to Cloudflare, and they are located in prism land.
> Cloudflare is rapidly becoming a bitcoin community SPOF.

2023-06-07 15:03:23

- reply

📅 Original date posted:2013-06-14
📝 Original message:my initial idea (not sure if it is good) was to have an asymetric market.
lets say you want to create altcoin ALC. ALC are merge-mined with btc,
though without block reward.
to create 1 ALC you have two choices: destroy 1 BTC, or buy 1 ALC for a
floating amount from an exchange.
in my book, this would automatically lead to a slightly lower price for
1 ALC, and an automatic ceiling of 1 BTC, since you could always
sacrifice BTC to gain ALC.
but it would not diverge drastically lower, since apparently somebody
was willing to destroy 1 BTC to create it. maybe it could even trade
slightly higher because traded ALC could be spendable instantly while
sacrificed ALC would need a 120 blocks maturing period.
the "beauty" of that system is also it does not inflate the
cryptocurrency realm.
Andreas
Am 14.06.2013 23:10, schrieb Luke-Jr:
> Note that the "earn a mixture of BTC and TBC, but not both in full volume"
> only works for TBC because the price is by definition fixed with BTC.
> I'm not sure how you could implement something like this for an altcoin where
> the price is floating independently of Bitcoin.. that is, how you would know
> the right amount of Bitcoin to require sacrificed.

2023-06-07 10:44:55

- reply

📅 Original date posted:2012-12-03
📝 Original message:These discussed features are all useful but quite contradicting.
I imagine that a user will be able to switch between different coin
selection policies "minimize fees","max privacy","defragmentation","i
don't care" and even switch between them for individual sends.

2023-06-07 10:43:42

- reply

📅 Original date posted:2012-12-06
📝 Original message:During/before the Payment Request there should be a method to exchange
the public keys to be able to generate a common multisig address.
Should this be handled in a different protocol, or be included in this
spec?
Or is there a method for the customer to verify that the specified BIP16
Output contains his address and the one from an escrow service?
--
Andreas

2023-06-07 10:25:36

- reply

📅 Original date posted:2012-07-27
📝 Original message:I propose a pragmatic solution: Try running the Multibit client. i am
not sure if the linux/java based installer would work,so maybe you have
to build it from source.
I tried it out is really fast compared to bitcoin-qt. after install it
took me 15 seconds to get updated and running. Importing a private
key/rescanning the blockchain was done in under 30 minutes.
It requires Java 6, i think there is a distro even for freebsd.
of course, you cannot do things as solomining with it since it uses SPV.

2023-06-07 10:23:43

- reply

📅 Original date posted:2012-07-23
📝 Original message:Some concerns regarding Bloom Filters. I talked with Stefan Thomas on
the Hackathon Berlin about this.
I tried to follow the discussion closely but i have not taken a look at
the code yet (is there already an implementation?) so please correct me
if i got something wrong.
The way the Bloom filters are planned now this requires a complicated
setup. basically the client will ask the server to replay the whole
blockchain, but filtered.
This is not optimal for the following reasons:
This will require the server to do a full scan of his data and only
filter out non-matching entries.
Really lightweight clients (like Bitcoincard), clients with shared
private keys (electrum-style), or brainwallets - will ask the following
question quite often to "supernodes": Given my public keys/addresses,
what is the list of unspent outputs. i think it would make sense to
include such a command, instead or in addition to the filterload/filterinit.
And perhaps more severe: as far as i understand classic bloom filters,
the server has no method of indexing his data for the expected requests.
There is simply no data structure (or maybe it has to be invented) which
allows the use of an index for queries by bloom filters of *varying
length* and a generic hashing method.
im not sure what a really efficient data structure for these kinds of
query is. but i think it should be possible to find a good compromise
between query flexibility, server load, client privacy.
one possible scheme, looks like this:
the client takes his list of addesses he is interested in. he hashes all
of them to a fixed-length bit array (bloom filter) of length 64KiB (for
example), and combines them with | to add more 1's with each address.
the server maintains a binary tree data structure of unspent outputs
arranged by the Bloom filter bits.
to build the tree, the server would need to calculate the 64KiB bits for
each address and arrange them in a binary tree. that way he can easily
traverse the tree for a given bloom query.
if a client whishes to query more broadly he can calculate the bloom
filter to 64KiB and after that fill up the last 50% of the Bits with 1.
or 95%. the trailing 1 bits even don't need to be transmitted to the
server when a client is querying. of course, if the client is more
privacy-concerned he could also fill up random bits with 1, which would
not change much actually.
the value of 64KiB is just out of thin air.
according to my experimentation using BloomFilter from Guava -
currently, also 8KiB would be sufficient to hava a 3% false positive
rate for the 40000 active addresses we have right now.
someone more familiar with hashing should please give his opinion if
cutting a bloom filter in half has any bad consequences.
Andreas

2023-06-07 10:23:11

- reply

📅 Original date posted:2012-07-17
📝 Original message:Am 17.07.2012 11:17, schrieb Amir Taaki:
> Like I really do not wish to sell a speaker slot, but if I have to (to pay the bills) then it will be obvious due to scheduling and disclaimers that speakers are sponsors.
>
>
Personally, i really don't mind sponsored speakers. If they have
somewhat relevant topics they keep the event from becoming a "circlejerk".
for example i would really like to hear about payments innovation
outside bitcoin.