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
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
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
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.
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
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
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.
--
See everything from the
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
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
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
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
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
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
13 matches
Mail list logo
